不过虽然在关系数据库中的需求在键/值数据库已大为减少，有些东西还是不可避免的。那些关系一般存在于核心实体之间。比如说，定单系统会有这样一些 项目，其中包含有客户、产品及定单的数据。 这些是否在相同或不同的域都是无关紧要的；但是当客户下单时，你大概不会想把客户和产品的属性都放进同一张定单里吧。
相反，定单需要包含相关键值指向客户和产品。尽管这在键/值数据库是完全可行的，这些关系却不会在数据模型本身内进行定义，因此数据库管理系统是无 法强制要求这些关系的数据一致性的。这意味着你可以删除客户及其已订购产品。确保数据完整性的责任完全落在了应用的身上。
键/值存储:优点
有两点键/值数据库是明显优于关系数据库的。
云的最佳搭档
第一个好处是它们简单，并因此比关系数据库伸缩起来要自如得多。如果你正在打算把一个内部系统聚拢起来，试图把预期中规模庞大的伸缩需求交给数据仓 储背后那数十上百台服务器去处理，那么就请考虑一下键/值存储。
由于键/值数据库简单，且动态可扩，它们也是提供多用户、web服务的平台数据存储的供应商的选择。这种数据库提供了相对廉价的设计存储平台，并拥 有庞大的扩充潜力。用户通常只需用多少就给多少，而其需求增长时配额能随之而增。与此同时，供应商能基于总用量动态扩充平台，整个平台的大小几乎不受限 制。（译者：最典型的就是各种所谓支持多少G的邮箱应用了）
编码得心应手
关系数据库模型和应用代码对象模型通常是以不同方式建立起来的，这导致了不兼容性。开发人员通过将代码映射到关系模型去克服这种不兼容性。这个过程 一般被称为 对象-关系映射，基本上等于是“管道”代码，没有直接明确的价值，却耗费掉了应用开发的大量时间和精力。另一方面，许多键/值数据库在结构中保留的数据， 与底层代码中的对象类的映射关系却要直接得多，从而显著减少了开发时间。
其它一些支持这种数据存储的理由，比如“关系数据库相比之下更为笨拙（不管这意味这什么）”等，则不太令人信服。不过在跳上这趟键/值数据库的列车 之前，请先考虑一下它的缺点。
键/值存储: 缺点
关系数据库固有的约束保证数据在最低层次拥有完整性。违反完整性约束的数据在物理上进不了数据库中。这些约束在键/值数据库中是不存在的，因此确保 设计完整性的责任全部落到了应用程序的肩上。但是程序会经常出现Bug。在一个设计得当的关系数据库里，Bug通常不会导致数据完整性问题；但是在键/值 数据库里的bug就很容易引起数据完整性问题。
关系数据库另一项关键的好处就是它强迫你经过一个数据建模的过程。如果做得好，这个建模过程所创建出的数据库的逻辑结构，就应该是映射它所要包含的 数据，而非映射应用程序的结构。然后数据从某种程度上就变得是独立于应用的，意味着其他应用同样也能使用统一数据集，从而应用逻辑的改变不会影响到底层的 数据模型。而键/值数据库要实现这一过程的话，就要以类的建模实践替代关系数据建模，以便在数据的自然结构基础上创建出通用的类。
还有别忘了兼容性。面向云的数据库不像关系数据库，并没有多少办法去共享标准。尽管它们都有着类似的概念，却各有着自己的API、特定的查询接口及 特性。因此，你真的要信任你的供应商，因为就算你对服务不满意也覆水难收了。还有，由于目前所有的键/值数据库均处于测试阶段，这种信任的风险可比对老派 的关系数据库要高的多。
分析上的限制
在云内，键/值数据库一般是多租户的，这意味这许多用户和应用将使用同一系统。为了防止任一进程导致共享环境过载，大部分云数据存储严格限制了单一 查询可能导致的总影响效应。举个例子，在 SimpleDB里，你不能执行过程超过5秒钟的查询。而在Google的AppEngine Datastore里，任何查询结果都不允许超过1000条。
这些限制对于你的面包-奶油式的应用逻辑（添加、更新、删除、获取少量内容）而言不成问题。但是当你的应用取得成功的时候会发生什么呢？你已经攫取 了许多用户，获得了大量数据，现在你想为客户创造新价值，或者也许还想利用这些数据产生新的收入。你就会发现自己被严重限制了，甚至连直接的分析型查询都 很困难。在此类平台上，类似追踪（用户的）使用模式、基于用户历史提供建议等事情，即便不是不可能也是非常困难的。
这种情况下，你将不得不实现一个从键/值数据库分离出来的，独立的分析型数据库，以便执行那样的分析。再想想你该在哪里才能做这样的事情？又该如何 去做？是不是应在云上维护它？还是投资于一个现场（译者：on-site对应于off-site，一般在IT外包中应用）的设施？你和云服务供应商之间的 延迟会不会成为问题？你现在的基于云的键/值数据库支持它吗？如果你的键/值数据库有10亿个条目，可是每秒钟却只能提供1000条结果，这样的查询该执 行多久才能完事呢？
归根结底，虽然规模是一项考虑因素，不要把它排在你将数据转换成为资产的能力的前头。如果你的用户，因为竞争对手拥有更酷更人性化的特性而跑掉，这 世上的一切伸缩性都将一无是处。
云服务竞争者
一些网络服务供应商现在提供了基于即用即付的多租户键/值数据库。大部分都符合我们这里讨论到的标准，但是每一个都有其独特之处，与迄今描述的一般 标准有所不同。现在让我们看看这些特定的数据库，分别是SimpleDB， Google AppEngine Datastore和SQL Data Services。
亚马逊: SimpleDB
SimpleDB 是一个亚马逊网络服务平台的一个面向属性的键/值数据库。SimpleDB仍处于公众测试阶段；当前，用户能在线注册其“免费”版 --免费的意思是说直到超出使用限制为止。
SimpleDB有几方面的限制。首先，一次查询最多只能执行5秒钟。其次，除了字符串类型，别无其它数据类型。一切都以字符串形式被存储、获取和 比较，因此除非你把所有日期都转为ISO8601，否则日期比较将不起作用。第三，任何字符串长度都不能超过1024字节，这限制了你在一个属性中能存储 的文本的大小（比如说产品描述等）。不过，由于该模式动态灵活，你可以通过追加“产品描述1”、“产品描述2”等来绕过这类限制。一个项目最多可以有 256个属性。由于处在测试阶段，SimpleDB的域不能大于10GB，整个库容量则不能超过1TB。
