该公司的这项工作已经开始了一段时间了；事实上早在一年前Amazon就推出了这个计划的早期版本，一些用户已经从那个时候开始使用该产品了。在那之后，Amazon又对SimpleDB做了许多调整改进工作，很明显这是Amazon在听从客户建议之后所做的努力。
现在推出的这个测试版（任何人都可以使用）与客户理想中的最终产品越来越接近。我现在已经决定试用一下，因为我是Visual Studio的研发者，我所选择的工具是C#Visual Studio库（Amazon也为其他包括Java，Perl和PHP在内的平台提供了几种官方库）。
使用
SimpleDB采用了一种很独特的存储方法，使人们可以在云基础的应用软件上存储简单数据。这种方法与电子表格程序类似，并且一定是非关联性的。（这让我想起了Google的BigTable。这个软件能通过Google App Engine运用到一个叫DataStore的小型表格中去。）当SimpleDB不能满足你的要求时，Amazon还提供许多其它的数据库。 比如说公司提供Amazon Simple Storage用于存储文件。EC2（弹性计算云）是这个软件的主要云平台，在这个平台上，你可以运行任何数据库服务器，其中也包括了SQL服务器。这就意味着你并不是只能选择SimpleDB。
总览
SimpleDB（与Google的DataStore相类似）的主要宗旨就是阅读速度快。虽然并非全部的网站都需要快速进行资料检索，但至少绝大部分的网站有这样的需求，而且它们对资料检索速度的要求远远高于对资料存储的要求。Amazon的自有网站就是一个典型的例子。人们在Amazon的网上浏览书籍和其它产品，一定希望很快就能打开相应的网页。此时，除了记录下你的浏览历史之外，基本上没有什么资料存储工作。人们可不想苦苦等待这些网页慢慢打开。但又比如说当人们在Amazon的论坛上发帖时，最后的帖子发布过程会有延迟——这段时间虽然很短，但大家还是可以发现。可显然大家对这个现象表现出了相当的宽容。总的来说，对绝大部分人来说，让他们满意的应该是可以快的阅读速度以及相对来说可能慢一些的书写速度。这些就是SimpleDB（与Google DataStore）提供的主要功能。
尽管现在市场上大部分的数据库都是关系型的（并且采用的是SQL语言），可以肯定的是SimpleDB一定是非关联性的。用户并不是在表格相同的条条框框里创建资料，而是创建一个称为域的资料集用于存放资料项。每一个资料项能够有多种“属性”，每一个属性都可以单独命名。
这些就是SimpleDB与传统的关系型数据库大不相同的地方。SimpleDB提供的样本文件就是很好的例子。假定你想创建一个域用于存储产品信息。对你来说，一项产品有可能是一件衣服，这件衣服可能会有多种属性，比如说颜色，尺寸等等。另一项产品可能又是一件与衣服完全不同的产品，比如说是一个汽车引擎。汽车引擎的属性里不包括颜色与尺寸，但是却会有其他内容，比如说型号、生产年份等等。
在一个关系型数据库里，上文所说的那种情况有两种解决办法。一种就是创建两个不同的表格，另一个就是创建一个表格，但这个表格里会含有对某些产品来说并不存在的属性名称。（例如对汽车引擎来说，尺寸这一栏将留空。）但是在SimpleDB里，尺寸这一条在汽车引擎项里并不存在，同样对套衫这一项来说，也不会出现品牌和型号这类的条款。但是汽车引擎和套衫可以同时存储在一个单独的域里。
你可以在同一个域里创建下述数据：
l Item1: Category=Clothes; SubCategory=Sweater; Name=Cathair Sweater; Color=Siamese, Size=Small, Medium, Large.
l 项1：Category=Clothes; SubCategory=Sweater; Name=Cathair Sweater; Color=Siamese, Size=Small, Medium, Large.
l Item2: Category=Car Parts; SubCategory=Engine; Name=Turbos; Make=Audi; Model=S4; Year=2000,2001,2002.
l 项2：Category=Car Parts; SubCategory=Engine; Name=Turbos; Make=Audi; Model=S4; Year=2000,2001,2002.
要注意的是，两项产品同时拥有属性目录，支目录以及品牌这三项。但是其它的属性却是各自产品特有的。同时还要注意的是同一个属性值可以同时存储多个数值。对项1套衫来说，尺寸这项就有三个值，分别是：小，中和大。对项2引擎来说，生产年份同样有三个值：2000，2001和2002。
库以及访问方法
我提到过我选择了C#库。这里我想说明一点：这些库是Amazon自己编写的，但并不是唯一可供选择的库。SimpleDB的界面访问可以从下面两种方法中任意选一个：一是作为网络服务器（运用SOAP），另一个是REST（Representational State Transfer，代表性状态传输）。C#库包括了许多不同的类型和方法，这些类和方法都可以和SimpleDB互动。这些库会自动以一种隐蔽的方式创建URL，同时将它们发送到网络服务器，等待反馈。反馈将以下面的形式出现：（顺便提一句，如果你对REST非常感兴趣，网上有很多关于Amazon在创建自身界面时是否打破了非官方REST条例的讨论。这篇文章里就这个问题我不打算做更深入的讨论。但是如果你们对这些信息有兴趣的话，上网以SimpleDB REST为关键词用google搜索一下就可以找到这类信息。）
既然C#库可以简单地创建了REST请求，同时也阅读了反馈，事实上这个时候就可以开始着手创建你自己的类型库了。我想随着时间的推移，我们可以看到更多更好的库，因为Amazon现在创建的这个并不是十分的复杂。但既然这只是一个面向REST访问的库，所以我并不打算以这一个库为标准对SimpleDB的产品进行评判（我建议你们也别这样做）。
但是我的确有一个很关心的问题，那就是：所有的反馈都是以
Height
1
Width
2
12345678-1234-1234-1234-123456789012
0.0000012345
这样要回到双整数将要浪费很多空间。双整数只需要几个字节就可以存储下来，而这样的反馈大小却超过了400字节。如果你要做的是大量的数据修补工作，上述说的差异将会对结果造成巨大的影响。（这就意味着你将要确认自己将会批量访问数据而并非单独访问。多项数据资料可以仅出现一项反馈）
体验SimpleDB
C#库可能的确是有一些过于简单，但它运行良好。我可以很容易地把资料输入到SimpleDB服务器上。我运行编码创建域，从域里添加和移除资料，同时还可以将这些资料在域里进行排列。这些工作都进行得十分顺利。事实上这些就足够了，这也是SimpleDB所运求的——简洁。它是用于存储资料的。至于判定到底哪些是你的网站需要上传的资料，这可就是你自己的任务了。
当然利用C#库也给我们出了一个有趣的思考题：在处理网络相关问题的时候，C#通常意义上是一个基于服务器的语言。这就表示你可能需要将你的网站的主机建立在Amazon的EC2或者是你自己的网站上。这个网站一定要是一个ASP.NET站点，同时你将要创建C#代码以达到和AmazonDB服务器互动的目的。接下来你的客户将会浏览你的网站，他们根本不会知道在后台你的站点正在Amazon的服务器上存储资料。
但是这种现象合理吗？你建了一个自己的网站，但用的却不是自己的数据。你必须将你自己的服务器连接到位于另一个网络里的另一台服务器上才能获取数据。这样有意义吗？这个问题的答案取决于你们自己，我不能代替你们做出回答，但是这个问题摆在我们面前，没有办法忽略。
对基于服务器代码来说还有另一个选择，那就是把你网站的主机设在EC2上。这样结果会比上面的方法好一些。EC2支持Windows服务器，你可以创建ASP.NET站点。（如果你不想用ASP.NET的话，你也可以在EC2上使用其它平台和语言。）虽然这个方法比上面的方法好一些，但是你的服务器依旧需要连接上SimpleDB来进行资料处理。
当然，还有另一种可能性就是转向网络2.0版，创建一个可以生成包涵JavaScript代码网页的网站；这些网页可以利用AJAX连接上正确的网站。但这样做的话，将会带来很大的安全风险，因为你不会希望你的客户的浏览器可以直接从你的SimpleDB域上读写资料吧。此外，在默认情况下浏览器甚至不允许JavaScript利用AJAX访问那些拥有与主机不同URL域的网站。
还有另一种选择就是采用一种混合的办法，你可以让你的服务器先向SimpleDB服务器提出请求，然后再返回。
如果你打算利用SimpleDB创建一个站点的话，上述问题都十分重要，需要好好思考。通常情况下，我认识大家一般会将他们的基于服务器的代码放在EC2这个主机上，显然Amazon也是这样想的。如果你真的这样做的话，在考虑安全问题的同时，你还要就你应该如何获得这些数据以及利用浏览器可以干什么仔细权衡利弊。
结论：一个特别的方法
总的来说，SimpleDB对那些不需要进行关联的资料来说是一个非常好的方法。但这种方法是不是适用于每一种场合呢？答案是不。最普遍的例子就是，已经完全规范化的客户数据库、产品数据库和销售数据库将非常不适应这样的情况，除非你先从客户数据库中找到每一个客户的ID，再从销售域中找到每一个客户所购买产品的ID，然后再去产品域中找到那个客户所购买的产品列表，最后人工将它们关联起来。这个工作量极大，但通过一个关系型数据库，一个简单的两线或者三级SQL连接就可以轻松把这个工作完成。
不管怎么样，如果你只是需要能够快速查找资料，并不需要把这些资料关联起来的话（比如说让产品表单符合一些既定的标准），SimpleDB将是你最好的选择。【WatchStor独家译稿，未经许可禁止转载。合作伙伴请注明原作者及出处为WatchStor.com】
