0

跨多个数据库表维护唯一 ID 字段的最佳方法是什么？

我的数据库同时包含企业和人员，并且这两个实体都需要有一个与之关联的唯一 ID 字段。此外，还有其他表（例如地址）可以使用他们的 ID 作为外键来引用企业或个人。

我正在考虑的一些想法是：

  • 使用插入行时计算的非自动编号 ID 字段。这将解决我的唯一性问题，但是每当我想通过相关属性（例如通过地址）查找某些内容时，我都必须检查两个表，其中一个包含我正在寻找的记录。

  • 向自动编号 ID 添加前缀以标识要在哪个表中查找 ID，但是我在关联表中的 ID 字段可能会变成字符串或包含与它们关联的表的标志，我不确定这将如何影响性能。

  • 将人员和企业合并到一个表中。我的问题是人和企业有不同的属性，需要单独的字段，这违背了我的本性，因为我更喜欢为单独的实体提供单独的表。

  • 创建一个主表，其中包含一个唯一的 ID 字段、个人或业务的 ID 字段以及一个表明它是哪一个的标志。然后使用该 ID 作为我的外部参考 # 并在所有关联的表中。

  • 因为我不是 dba，所以我不知道一些更好的处理方法

无论我采用哪种解决方案，都需要能够轻松处理大量记录（这将要替换的数据库有几百万条记录）并且位于 MS Sql Server 上

4

8 回答 8

6

好吧，您无法使用该设置设置外键。单个外键不能引用两个可能的不同表。

我会执行以下操作之一：

您当然可以在地址表中为两个实体中的每一个使用两个单独的列。业务 ID 和人员 ID。FK 可以有空值，所以这没关系。然后您可以强制执行 FK 关系，这将使您避免出现数据完整性问题。

或者设置一个包含企业和人员但只有很少字段的父表（只有他们真正共有的那些 - 甚至可能只有一个 uniqueid 和一个记录类型），然后您可以有业务、人员、地址等的子表。

或设置单独的子表 - 业务，然后是业务地址，人员和人员地址等。然后您不需要在两个逻辑实体之间保持 id 的唯一性。

我忘记了一种可能性，如果你有多对多的关系，你可以有地址、业务、人员，然后是一些链接表、业务地址、人员地址。如果我有其他选择，我个人不会使用 GUID，因为它们会损害性能。

于 2010-06-18T19:14:59.033 回答
2

你也可以颠倒你的想法。

人或企业没有地址具有人或企业ID，而是具有地址ID。

在我的书中，这是一种更自然的思考方式……一个人有一个地址。

于 2010-06-18T19:15:00.643 回答
1

创建一个标识企业和人员的“超类型”表，并使用您的外键引用该表。这是这种情况的常见模式。请参阅：派对数据模型。

于 2010-06-19T06:48:56.597 回答
1

这就是 GUID 的用途。

于 2010-06-18T19:07:18.057 回答
1

执行此操作有几种不同的模式，但最简单且最灵活的是使用唯一标识符 (GUID)；大多数数据库都有一些构建这些的工具（例如 SQL Server 是 NEWID()）。它们比其他 ID 表格更大，但它们会完成您正在寻找的工作。

于 2010-06-18T19:08:03.483 回答
1

Some databases allow you to have foreign keys with null values. Some do not, and I cannot recall if SQL Server does. If yours allows it, you can have 2 ID columns in the address table, one that points to People and one that points to Businesses. That approach also has pros and cons; one of the cons being that it is probably frowned upon by your DBA, but if your database allows it, then perhaps it could be one of the alternatives.

于 2010-06-18T19:14:27.550 回答
0

GUID 可以作为唯一标识符，仅此而已。
GUID 的问题在于它们的大小，尤其是在您的数据库非常庞大的情况下。
它们不应用于连接（索引、外键、...）。
我们有这种精确的数据库设计，当记录数变得太大时，我们不得不改回整数。
我还要指出，您需要谨慎设计您的个人/企业/地址。这是多对多的关系。一个企业/个人可以有多个地址，一个地址可以是多个企业/个人...

如果您想将企业和个人分开，您可以有 2 个表PersonAddress和BusinessAddress来保存关系，并且在查找两者的地址时必须进行联合，或者您可以为两个企业和一个单一的表 EntityAddress人和EntityNature 字段一起告诉它是企业还是个人。

于 2010-06-18T19:21:31.387 回答
0

企业和人真的，完全，独立于企业吗？

他们没有什么共同点，甚至没有“他们出生的那一天”？

商家不把他们俩都当作“交易对手”吗？

我要说明的是，您对业务足够认真，没有普通 IT（所谓的）“专业”通常会通过的通常令人眼花缭乱的眼镜，那么您将很快找到您正在寻找的共同点为了。

在您的数据库中定义一个表来记录这些共性（即使它只是标识），并使地址引用该表。

于 2010-06-20T23:34:14.853 回答