4

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

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

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

还有一些喜欢经典键的场景：

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

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

对所有表一揽子使用 GUID 是个好主意吗？

4

1 回答 1

6

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

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

于 2014-04-29T15:34:01.910 回答