用于复制的整数主键
我正在权衡可用于多主复制的整数主键的选择。 （我非常喜欢使用整数键而不是 GUID）
我能想到的最好办法是首先拥有最重要的数据，最后是服务器编号： 例如。服务器 1 上的发票 1 = 101 服务器 2 上的发票 1 = 102 其中非 serverno 部分 (invoiceno) 来自
算法上的数据库编号生成器： gen_id(INVOICENO_GEN, 1) * 100 + serverno 您可以通过查看值和数学计算来获取服务器编号。
这为 99 个服务器留下了空间，同时仍然简短、可读并且不会发生冲突。使用该方案和正常整数大小列将使最大行数 (21 474 836) 或者如果使用 bigint 则达到数十亿。
例如，发票表键如下所示：
Server 1
101
201
301
401
Server 2
102
202
302
402
所以我的问题是：我忽略了任何批评或缺陷吗？
数据库是Firebird。
I am weighing my options for integer primary keys that can be used in multi master replication. (I'm pretty much sold on using integer keys instead of GUIDs)
The best I can come up with is having the most significant data first and having the server number last:
eg. invoice 1 on server 1 = 101
invoice 1 on server 2 = 102
where the non serverno part (invoiceno) comes from a db number generator
algorithmically: gen_id(INVOICENO_GEN, 1) * 100 + serverno
and you can get the server number by both looking at the value and mathematically.
Which leaves room for 99 servers while still being short and readable and won't collide. Using that scheme and normal integer size column would make the max rows (21 474 836) or if bigint is used many billions.
for instance the invoice table keys would look like this:
Server 1
101
201
301
401
Server 2
102
202
302
402
So my question is: any critiques or flaws I have overlooked?
The database is Firebird.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只创建一个复合主键怎么样？
定义要在每个服务器上设置的“ServerID”，例如 1、2、3、4 等，作为 INT。然后将“InvoiceID”作为 Invoice 表中的 INT。
创建主键为 (ServerID,InvoiceID)。
这样，您就有足够的空间容纳超过 99 台服务器，并且您不必操纵/计算任何 ID 或类似的东西。
当然，引用 Invoice 表的任何表现在也需要使用 (ServerID,InvoiceID) 作为外键 - 但我想如果您需要复制这些表，那么在表中的任何地方都使用 ServerID 不会成为问题， 也。
马克
How about just creating a composite primary key?
Define a "ServerID" to set on each server, e.g. 1, 2, 3, 4 etc. as an INT. Then have the "InvoiceID" as an INT on your Invoice table.
Create the primary key to be (ServerID,InvoiceID).
That way, you have room for way more than 99 servers, and you don't have to manipulate / calculate any ID's or anything like that.
Of course, any table referencing your Invoice table now needs to use (ServerID,InvoiceID) as the foreign key, too - but I guess having the ServerID everywhere in your tables isn't going to be a problem if you need to replicate those tables, too.
Marc
一般来说，不要对任何非数字的内容使用数字类型。处理具有特殊意义的数字会使您的数字不再是严格的数字。字符串通常更适合这样的场景：您想要添加一些特定于环境的数据（通常用于复制）。
In general, don't use numeric types for anything that isn't a number. Treating the digits with special significance makes your numbers no longer strictly numeric. A string is usually more suited to scenarios like this where you want to add some environment-specific data (usually for replication).