使用 GUID 主键和同一数据库中不同表的主键自增
因此，我正在使用 MS SQL 设计一个数据库，其中包含发票表和客户表。我的客户表看起来像：
--------------------------------
Client ID | Name | Phone | Address | City | State | Zip
________________________________
其中客户端 ID 是 GUID 主键。
我的发票表看起来像这样：
--------------------------------
Invoice ID | Client ID | Date/Time | Price
________________________________
发票 ID 是一个数字（从 1000 开始）并自动递增 1。
这是可以的还是不好的做法？我只是不希望打印发票时使用发票 # 336868de-7778-41fc-ae7f-662f76d5615a....
So I'm designing a database using MS SQL with an invoices table and a clients table. My clients table looks something like:
--------------------------------
Client ID | Name | Phone | Address | City | State | Zip
________________________________
Where the client ID is a GUID primary key.
My invoices table looks something like:
--------------------------------
Invoice ID | Client ID | Date/Time | Price
________________________________
Where the invoice ID would be a number (starting at say, 1000) and auto-incrementing by 1.
Is this ok, or bad practice? I just don't want my invoices to be printing out with invoice # 336868de-7778-41fc-ae7f-662f76d5615a....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我个人认为没有理由使用 GUID - 如果我需要自动生成的东西，那就是身份。所以回答你的问题，完全没问题。正如 Martin 评论的那样，我也会考虑为您的客户 ID 使用自动编号。
I personally don't see a reason to ever use a GUID - if I need something auto-generated, identity it is. So to answer your question, that's perfectly fine. And as Martin commented, I'd consider using an auto-number for your customer ids as well.
一般来说，我认为不同的 ID 号使用不同的数据类型不一定有什么问题。
不过，我确实认为您可能需要重新考虑发票的自动增量编号。我认为没有任何平台可以保证自动增量 ID 号不会出现间隙。
会计师唯一比差距更讨厌的就是没有支持文件的差距，而这就是你将要拥有的。 （当然，有支持文档的差距并不是真正的差距，因为您可以考虑所有数字。）
In general, I don't think there's anything necessarily wrong with having different data types for different ID numbers.
I do think you might want to reconsider an autoincrement number for invoices, though. I don't think any platform guarantees that autoincrement id numbers will be without gaps.
The only thing accountants hate worse than gaps are gaps without backing documentation, and that's what you're about to have. (Of course, a gap that has backing documentation isn't really a gap, because you can account for all the numbers.)
如果您有可能将表移植到其他数据库，则 GUID 主键就有意义。如果您认为这对于客户端来说是正确的，但对于发票而言则不然，那么我不认为这两种不同的密钥类型有问题。但是，看看您的特定示例，由于存在依赖性，发票和客户端可能会一起移植。在这种情况下，两个表可能应该具有相同的主键类型。
GUID primary keys make sense if there is a reasonable chance you'll be porting the table to a different database. If you feel this is true for Client but not for Invoice, then I don't see the two different key types as a problem. However, looking at your particular example, Invoice and Client may be ported together since there is a dependency. In that case, you should probably have the same primary key type for both tables.