使用自定义表的GUID？

Question

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

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

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

还有一些有利于经典键的风格：

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

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

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

Answer 1

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

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