增加增量大小以匹配 GUID 优势
我一直在考虑实施这个系统，但不禁觉得有些地方有问题。使用 GUID 而不是递增 int 的要点之一是，将来如果您要将数据库合并在一起，则不会在主键/标识符上发生任何冲突。但是，我的方法是将增量大小设置为 X，其中 X 是我将来最有可能拥有的服务器数量。然后，在每台服务器上，让种子数比前一服务器上的种子数增加。这样，在合并过程中，就不会与主键发生冲突。这是一种安全、正常的方法还是我疯了:)？ 谢谢
I've been thinking of implementing this system, but can't help but feel there's a catch somewhere. One of the points of using GUID over incrementing int is that, in the future, if you were to merge databases together, you wouldn't have any clashes over the primary key/identifier. However, my approach is to set the increment size to X where X is the number of servers I'll most likely have in the future. Then, on each server, have the seed be an increment over the seed number on the previous server. That way, during merging, there would be no clashes with the primary key. Is this a safe, normal method or have I gone mental :)?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在多主 SQL 复制中，您通常将主键定义为：
整数 GUID 的缺点是它们可能更难以读取并且占用更多空间。但是，它允许您扩展到n 个实例。
整数更容易处理一些。它们还具有能够轻松判断哪个服务器创建了记录的优点。缺点是您必须预测可能合并的数据库的最大数量，或者猜测单个实例可能插入的最大行数。
固定偏移量的示例是：站点 A 从 0 开始，站点 B 从 1,000,000 开始，站点 C 从 2,000,000 开始。在一个站点插入一百万行之前，该方案可以正常工作。此方案可能非常适合汽车经销店的汽车，其中任何一个经销商不可能销售超过 1,000,000 辆汽车，并且在应用程序的生命周期内您可能拥有数百家经销店。
In multi-master SQL replication, you typically have primary keys defined as:
The downside of GUIDs is they can be harder to read and take up slightly more space. However, it allows you to scale to n instances.
Integers are a bit easier to deal with. They also have the advantage of being able to easily tell which server created a record. The downside is you must either predict the maximum number of databases which might be merged, or guess the maximum number of rows a single instance might insert.
An example of a fixed offset is: site A starts at 0, site B starts at 1,000,000 and site C starts at 2,000,000. This scheme works fine until one site inserts one million rows. This scheme might work well for cars at car dealerships, where it's unlikely that any one dealer would ever sell more than 1,000,000 cars, and you might have hundreds of dealerships over the life of the application.
让我害怕的是你使用“最有可能”。你在这里假设未来，通常这对这样的事情来说并不是一件好事。为什么不使用 GUID？
如果您在您认为拥有的基础上添加一台额外的服务器会怎么样？我可以看到事情很快变得非常复杂。
What scares me here is your use of "most likely". You're assuming on the future here, and typically that's not a good thing to do with things like this. Why not use a GUID?
What if you add one extra server over what you thought you'd have? I could see things getting really complicated really quickly.