问使用GUID将多个表链接到同一个Id字段是否被认为是良好的SQL实践？

EN

默认情况下，数据库不支持这种关系(正如您绘制的那样)。我以前使用过它，但没有强制使用多个不同表的外键。我必须处理代码中的所有关系。一般认为这是个坏主意。

“正确”的方法是有一个CardLocation、PhotographLocation等表，每个表都有自己的Guid主键(例如CardLocationId)。如果您碰巧需要在每个关系上挂起公共数据，那么您将创建另一个名为LocationRelationship的表，并使关系表的主键(例如，CardLocationId)也成为引用LocationRelationshipId的外键。因此，CardLocation中的每个记录在LocationRelationship中都有相应的记录。这样，您就可以强制执行关系数据库中的所有关系。不幸的是，事情要复杂得多。

编辑

经过更多的思考后，另一种方法是让Card、Photograph等从一个公共基础派生出来(让我们称之为Locatable)。因此，您可以创建一个名为Locatable的新表，其中包含主键LocatableId。那么CardId既是主键，也应该是引用LocatableId的外键，PhotographId也是LocatableId的外键。然后，您只有一个名为LocatableLocation的多对多表，其中包含指向LocatableId和LocationId的外键。

这是较少的表，似乎意味着意图更好。

我对你目前的数据模型有评论。

1-你应该有一个单独的m-m的每个关系，而不是像你目前在模型中显示的一个表。一个原因是m表的出现可能是一个或多个FK值。级联删除可能会删除may表中保存不想删除的FK值的几行。

2-你的关系，从一方到连接表，可能是可选的，从一方，而不是强制性的，因为你的模型。可选关系会导致创建一个可为空的FK，这将通过删除非空值并将其替换为null (如果这是您想要的话)来防止级联发生。

3-从m到Location表的关系可能不应该是强制性的，因为这会删除卡片删除上的位置。您可能希望这是可选的(见上文2)。

你真的需要m-m？真的吗？你的生意从问题上还不清楚，但也许你只需要一米。在你建立模型之前，先用一个例子来证明给自己看。

5-通过创建一个带有类型列的资源表，您可能会避免拥有4个可能具有相同列的表。类型是:卡片，插图，等等。这样你就可以保存3张表和3张连接表。

6-使用复数表名是不好的。微软曾经这样做过，但这并不好！更喜欢单数表名。复数名称有利于命名集合。

现在，根据您关于GUID的问题，您可以使用GUID，但这将使测试变得非常困难。如果GUID是您系统中的一个预期函数，它还会使使用GUID查找行成为用户的噩梦。大型数据库的性能可能会受到影响。考虑在可能的情况下使用int类型。将Horor - GUID编码为PK Pros Pros和Cons。

GUID通常表示为十六进制字符串，但如果空间是考虑因素，则更适合以二进制格式(而不是varchar)存储；通常是在RDBMS中。

使用GUID作为外键或主键没有任何问题。如果您确保您的表有正确的索引，那么它根本不应该影响性能。