使用自定义表的GUID？

Question

据我所知,SAP CRM和HANA都使用GUID来唯一标识记录,而不是使用经典的递增整数.是否有涵盖其使用的最佳实践或明确指南？

以下是我考虑过支持GUID的一些因素:

• 离线创建对象.在这些情况下,IIRC GUID几乎保证是独一无二的,因此合并或整合不同的数据集不是问题.
• 代理键具有明显的开发优势.虽然递增整数是代理键的一种形式,但使用不同的数字序列可以对它们施加功能意义.

还有一些有利于经典键的风景:

• 用户需要人类可读的密钥来识别系统中的记录.这可以通过指定具有可读值的外部ID在GUID表中处理.
• 用户希望使用数字序列来识别不同类型的记录,类似于销售或购买文档.虽然我实际上认为这个糟糕的设计.

自定义开发的哪些场景会让您更喜欢GUID而不是经典键？

是否对所有表的GUID进行全面使用是个好主意？

Answer 1

最后回答这个问题:不,它不是(至少不是在ABAP环境中,我怀疑它在其他地方是明智的).在任何地方使用主键的GUID使得在运行时维护和遵循复杂的外键关系非常困难.想象一下,必须调试一个使用GUID处理所有内容的程序,而不是您习惯使用的语义键.请记住,主键的总长度不得超过255,如果您希望能够使用完全限定键传输表条目,则主键的总长度不应超过120.在复合键中使用GUID会不必要地打开键,并将它们用作合成键使得使用外键关系几乎不可能.所以不,在任何地方使用GUID都不是一个好主意,尤其不适用于配置/自定义数据.

然而,在"老派ABAP开发"中使用数字范围对象的几乎每个地方都使用GUID是个好主意.GUID可以由应用程序服务器生成,而数字范围需要与排队服务器进行网络通信.(是的,有一些缓冲涉及,但一般来说,GUID更快,更容易处理).因此,除非您需要密钥遵循某种模式,否则您应该考虑使用GUID.即使您出于任何业务原因需要某种序列号,使用GUID作为主键并将序列号存储在(索引)属性中以增加开发时的灵活性可能也是明智的.