在 DynamoDB 中建模关系数据的最佳实践
传统关系数据库管理系统 (RDBMS) 平台在规范化关系结构中存储数据。此结构将分层数据结构简化为一组存储在多个表中的公共元素。下面的架构是通用订单输入应用程序的示例，支持 HR 架构可支持理论制造商的运营和业务支持系统。
RDBMS 平台使用即席查询语言（通常倾向于 SQL），生成或具体化规范化数据视图以支持应用程序层访问模式。
例如，要生成按照可发运每个项目的所有仓库库存数量排序的采购订单项目列表，可以对上述架构发出下面的查询。
SELECT * FROM Orders
INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID
INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID
INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID
ORDER BY Quantity_on_Hand DESC这种一次性查询提供用于访问数据的灵活 API，但需要大量处理。您必须经常从多个位置查询数据，而且必须汇总查询结果进行演示。上述查询对多个表发起复杂查询，然后排序并汇总得到的数据。
可能降低 RDBMS 系统速度的另一个因素是需要支持符合 ACID 的事务框架。大多数在线事务处理 (OLTP) 应用程序使用的层次数据结构存储在 RDBMS 中，必须分解并分布在多个逻辑表。因此，需要一个符合 ACID 的事务框架，避免应用程序尝试读取正在写入的对象时可能发生的争用情况。此类事务框架必定会大幅增加写入开销。
这两个因素是扩展传统 RDBMS 平台的主要障碍。NewSQL 社区是否可以成功提供分布式 RDBMS 解决方案还有待观察。但这几乎不可能解决前面提到的两个局限性。无论提供怎样的解决方案，规范化和 ACID 事务的处理成本还是非常高。
为此，如果业务需要低延迟响应高流量查询，采用 NoSQL 系统通常具有技术和经济意义。Amazon DynamoDB 可以避免这些限制，帮助解决问题。
关系数据库系统无法正常扩展的原因包括：
规范化数据并存储在多个表中，需要多个查询以写入磁盘。
通常产生 ACID 合规事务系统的性能成本。
使用成本高昂的连接，重新组织需要的查询结果视图。
DynamoDB 可以正常扩展的原因包括：
架构灵活性支持 DynamoDB 在单个项目内存储复杂层次数据。
复合键设计支持将相关项目一起存储在同一个表。
针对数据存储的查询变得简单得多，通常采用以下形式：
SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"
与前面示例中的 RDBMS 相比，DynamoDB 可以更轻松返回请求的数据。