您正在比较苹果和橙子，并且对于您应该选择一种与另一种情况的方案没有正确的答案。但客观地说，存在一些不同的差异：
- 表存储每个分区最多支持2,000个事务/秒（由您选择的分区键决定），整个存储帐户支持20,000个事务/秒。交易数量无法保证，并根据实体规模而有所不同
- DocumentDB虽然每秒不提供“交易”，但却提供每秒保证级别的“请求单位”。通过测量各种查询，您可以扩展数据库，以提供应用所需的每秒等效事务数。 DocumentDB允许您调整给定集合的RU，有效地允许您扩展到比表存储更大的事务速率（您当然可以利用多个存储帐户来提高有效的表存储事务速率）。 DocumentDB为每个集合提供高达10K RU /秒（标准集合）或250K RU /秒（分区集合），并且可以根据需要提高每个支持的限制。
- 表存储支持实体组事务，允许将最多100个实体（以及最多4MB有效负载）的操作批处理到单个原子事务中。事务绑定到单个分区。
- DocumentDB允许事务在集合的范围内发生。如果在存储过程中执行了多个数据库操作，那么这些操作将成功或以原子方式失败。
- 表存储是键/值存储，并且对分区键+行键的查找可以产生非常有效的点查找。一旦开始检查PK / RK以外的属性，您将输入分区扫描或表扫描的空间。
-
DocumentDB是一个文档存储，您可以索引文档中的任何/所有属性。
-
每个帐户的表存储量为500TB。
- 如果您请求额外的存储空间（例如500TB），则每个集合的DocumentDB可扩展至250GB。
- 表存储通过存储访问密钥提供安全性。有一个主存储帐户密钥，以及生成共享访问签名以提供特定表的特定访问权限的功能。
-
DocumentDB具有读/写和只读管理密钥，以及对集合/文档的用户级访问
-
表存储和DocumentDB具有非常不同的定价模型（表存储只是每GB每月成本，以及交易的名义成本）。但回到我对苹果与橘子的观点：DocumentDB是数据库引擎 - 查询语言，服务器端程序，触发器，索引等。
我确信我错过了一些客观的比较，但这应该为你做出决定使用其中一个，另一个或两者的一个很好的起点。您如何选择将这些应用程序应用到您的应用程序中取决于您，以及您的优先级（缩放？查询？成本等等）。