这是设计数据库的标准方法吗？

我最近了解了如何在工作中的数据库中定义关系，并且想知道这是否是标准做法。

假设我们有两个流程：流程A和流程B。流程B取决于流程A的结果，因此需要在流程B运行和流程A运行之间定义一种关系。关系的定义方式如下：

TableProcessA:
Id

和

TableProcessB:
Id
ProcessAId

现在，到目前为止，事情对我来说还是有意义的，但是后来事情对我和我对表格设计的理解变得有些奇怪。每当在TableProcessA或TableProcessB中创建一行时，都会调用一个函数，该函数为每个函数创建一个全局唯一的ID。因此，基本上，TableProcessA和TableProcessB中的所有Id字段都将不包含任何匹配项，因为Id不仅是其表唯一的，而且对于整个数据库都是唯一的。

我的问题是，这是什么标准？我想到了一个想法，即每个表都应该仅具有一个自动递增的ID，该ID仅对表而不对整个数据库唯一。

这不是一个奇怪的做法。这些称为GUID，即全局唯一ID。这个想法是，给定一个GUID，您可以准确地知道id属于哪条数据，因为id在任何地方都是唯一的。当您要合并相似数据的不同来源时，最好使用GUID。例如不同商店的库存。

我将进行一些研究，以找出为什么这在您的环境中很普遍。也许是需要的，也许不是。

原则上，在整个数据库中拥有唯一的ID并不太坏，但是根据我的经验，这很不寻常。除非有维护全局唯一性Id密钥的特定要求，否则使用正常身份应该是可以的，因为实体类型或对象倾向于特定于类型，并且通常不会导致任何不适当的联接。

除了您的问题外，我强烈建议不要将GUID用作主键或代理键，因为它占用的空间是整数的4倍。现在，在数千兆字节的磁盘时代，您可能会说这并不重要，但是当您拥有数百万行的数据时，它仍然需要资源来从磁盘读取或通过网络进行传输，如果它们包含在任何索引中，则更是如此。当我在主题索引上时，由于存在随机性，GUID在主键上是不好的，通常会造成很大的碎片。

现在对于该数据库来说可能为时已晚，但请记住以备将来使用

您的流程可以创建包含GUID作为对流程实例的引用的记录，但是使用GUID作为键不一定是最佳的。

我看到了将GUID用作数据库密钥的三个主要缺点，并且除非有充分的理由使用它们，否则将避免使用它们。请注意，与使用表中本地唯一的键相比，全局唯一属性不会为您带来任何优势，因为您已经知道数据来自哪个表。

不便之处：如果要对数据库进行临时查询，那么键入GUID并不是一件容易的事，例如：

select *
  from Foo
 where FooID = 12345

与

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

后者实际上意味着您需要从中剪切和粘贴GUID的源。

2.自然顺序：自动递增的主键具有副作用，可以按照将交易输入系统的顺序自然地对您的交易进行排序。这通常非常有用。GUID通常不按顺序生成，因此在这方面没有用。

3.大小：如今问题不大，但GUID长16字节。它在表以及包含它的所有索引中占用更多空间。

我不会说这是正常的，但是以这种方式进行设置也不是异常。