是否可以在documentDB中使用标识列进行自动增量，它通常对ID很方便？任何与之相关的链接或提示都很有用。
感谢。
答案 0 :(得分：8)
AFAIK，DocumentDB没有这种概念。 DocumentDB中的每个文档都有一个id属性，该属性唯一标识文档，但id字段的类型为字符串。创建文档时，您可以选择不为此字段指定值，DocumentDB会自动分配ID，但此值为GUID。因此，如果您希望实现自动增量类型功能，则需要自己处理。但是请记住它是一个字符串类型的属性，所以即使你自己处理它，你需要用零填充你的字符串，以便以正确的顺序返回值，即1,2,3等。而不是1,10,11，...... 19,2,20 ......
答案 1 :(得分：5)
仍然（截至2016年8月）没有内置Identity功能;在DocumentDB的反馈论坛上有一个请求，可以投票给here。但请记住，自动计数器在某种程度上违背了大多数NoSQL设计理念。
然而，有几种方法可以作为解决方法，并且都有一个警告;第一种方法是使用存储过程中更新的Counter Document：
存储程序和计数器文件
创建一个包含数值属性的文档。要么缓存它的自我链接，要么最好使用已知的ID创建它，例如＆＃34; __ DocumentType _Counter＆＃34;然后你可以使用UriFactory构建一个文档链接，它允许高效的＆＃39;直接＆＃39;访问此Counter Document。
创建一个存储过程，接受要插入的文档和Counter Document的Uri。在此存储过程中，选择计数器的值，将其递增，将其分配给要插入的文档的相关属性，如果成功保留，则将增加的值保存为计数器文档的更新。
这种方法可行，因为存储过程会自动作为事务执行。
警告：但是，事务目前仅限于集合的边界范围内 - 在将文档插入另一个集合时，您无法在一个集合中使用此方法与Counter Document。
<强> Redis的
探索的第二个选项，增加了一点复杂性和一点额外费用，并且在增加和插入文档方面不完全交易（但在我个人的经验中提供）更高的吞吐量），是创建一个Azure Redis缓存，并将Counter值保存在Redis Key Value存储中，然后使用LUA脚本查询和递增。
这确保了Counter值及其增量的查询是一个原子事务，因为Redis是单线程的，LUA脚本基本上阻塞直到完成（但执行得非常快）。
也可以使用MULTI-EXEC命令..这些命令有其自身的问题，需要进行调查，看看它们是否与您相关。
可以找到有关Redis交易的更多信息here - Transactions in Redis
警告：如果您的文档仍然存在失败，那么您就有了“鬼魂”。 Ids，你可能接受也可能不接受。
更新：响应有关＆＃34的评论;为每个创建操作添加RU成本＆＃34;和＆＃34;序列化所有写入＆＃34; - 是的，显然，当使用Counter Document方法时，创建需要增加Identity属性的文档时就是这种情况;没有其他插入会受到影响。
这两项成本＆＃39;在使用DocumentDB时必须满足所需的功能 - 这本身并不支持Identity属性的概念;持久化到Document以确保恢复/连续性，序列化以保持一致性。在通常的情况下，RU成本可以忽略不计，并且可以使用诸如批处理之类的技术来抵消这种情况。
目前没有DocumentDB替代方案不会持久存在计数器或序列化写入，同时保证来自多个呼叫者的递增计数器的完整性。
DocumentDB团队的Andrew Liu的建议确实是使用Counter Document ，如linked question中所述 - 请注意以下评论Andrew＆＃ 39;答案。
由于存储过程是在DocumentDB中预编译的，因此它们是执行＆＃34;＆gt;的有效方式。 1＆＃34;操作。它们目前也是执行交易的最佳方式。 ＆＃39;某处＆＃39;必须是柜台的唯一真相来源;如前所述，一个选项是Redis，但正如我所指出的那样，如果文档插入失败，这不会被回滚的事务的一部分，这可能是也可能是不可接受的;例如，在事件采购中，它不是。