Amazon SimpleDB Identity Seed 等效项
SimpleDB 中是否有相当于身份种子的东西？
如果答案是否定的，您如何处理创建诸如客户编号或订单号之类的内容以防止创建重复的编号？
我的经验主要来自 SQL Server，其中我要么使用身份种子创建主键，要么使用存储过程中的事务来增加数字。
感谢您的帮助！
Is there an equivalent to an identity Seed in SimpleDB?
If the answer is no, how do you handle creating something like a customer number or order number that will prevent the creation duplicate numbers?
My experience is mainly from SQL Server in which I would either create a primary key with an identity seed or use transactions in a stored procedure to increment the number.
Thanks for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用条件写入创建唯一键。只需使用您想要使用的下一个客户编号和您想要存储的数据执行 PutAttributes 即可。您无法为实际项目名称添加条件，但可以使用始终存在的属性（例如创建日期或用户组）。
设置条件：
只有当具有该项目名称的项目中不存在creation_date时，调用才会成功。如果您总是写入creation_date，那么您就会在新项目名称上获得乐观锁定的效果。当然，您可以使用任何您想要的属性，只要您始终将其包含在第一个条件放置中即可。
在大多数情况下，条件写入的性能与正常写入相同，但当 SimpleDB 负载较重或内部网络延迟较高时，与正常写入相比，这些调用将花费更长的时间。在 SimpleDB 内部出现罕见故障的情况下，条件写入将在一段时间内完全失败。
如果您不能容忍这一点，则必须编写某种替代方法来在中断期间获取唯一密钥。不同的 SimpleDB 区域只能用于密钥生成，因为 SimpleDB 在中断期间仍将接受正常写入（非条件 PutAttributes）。
You can create unique keys using conditional writes. Just do a PutAttributes with the next customer number you want to use and the data you want to store. You can't add a condition for the actual item name, but you can use an attribute that always exists, (like creation date or user group).
Set the conditions:
The call will succeed only if there is no creation_date in an item with that item name. If you always write the creation_date, then you get the effect of optimistic locking on the new item name. Of course you can use any attribute you want, so long you always include it in that first conditional put.
The performance of the conditional write is the same as a normal write in most situations but when SimpleDB is under heavy load or high internal network latencies, these calls will take longer, compared to normal writes. During rare failure scenarios inside SimpleDB, the conditional writes will fail completely for a period of time.
If you can't tolerate this, you will have to code some sort of alternate way to get your unique keys during outages. A different SimpleDB region could be used for key generation only, since SimpleDB will still accept the normal writes (non-conditional PutAttributes) during outages.
如果您还没有可用的独特功能，那么使用项目的 GUID 可能是典型的解决方案。
If you don't already have something unique that will work, using a GUID for the Item is probably the typical solution.