据我所知，SAP CRM和HANA都使用GUID来唯一标识记录，而不是使用经典的递增整数。是否有涵盖其使用的最佳实践或明确的指导方针？
以下是我考虑过的有利于GUID的一些因素：
- 脱机创建对象。IIRC GUID在这些情况下几乎可以保证是唯一的，因此合并或集成不同的数据集不是问题
- 代理密钥具有明显的开发优势。虽然递增整数是代理键的一种形式，但使用不同的数字序列可以赋予它们函数意义
还有一些支持经典钥匙的场景：
- 用户需要人类可读的密钥来识别系统中的记录。这可以在GUID表中通过指定具有可读值的外部ID来处理
- 用户希望使用数字序列来识别不同类型的记录，类似于销售或采购文档。尽管我真的认为这个设计不好
自定义开发的哪些场景会使您更喜欢GUID而不是经典密钥？
对于所有表全面使用GUID是个好主意吗？
最后回答这个问题：不，它不是(至少在ABAP环境中不是，我怀疑它在其他地方是否合理(。在任何地方使用主键的GUID都会使在运行时维护和遵循复杂的外键关系变得非常困难。想象一下，必须调试一个程序，该程序使用GUID而不是您习惯的语义键来处理所有内容。请记住，主键的总长度可能不超过255，如果您希望能够使用完全限定的键传输表项，则主键的总长度不应超过120。在组合键中使用GUID会不必要地破坏键，并且将它们用作合成键会使使用外键关系变得几乎不可能。所以不，到处使用GUID不是一个好主意，尤其是对于配置/自定义数据来说。
然而，在"老式ABAP开发"中使用数字范围对象的几乎每个地方都使用GUID是一个好主意。GUID可以由应用程序服务器生成，而号码范围则需要与排队服务器进行网络通信。(是的，这涉及到一些缓冲，但一般来说，GUID要快得多，也更容易处理(。因此，除非您需要密钥遵循特定的模式，否则您应该考虑使用GUID。即使出于任何业务原因需要某种序列号，也可以使用GUID作为主键，并将序列号存储在(索引的(属性中，以增加开发时的灵活性。