mysql - 在考虑规范化和可伸缩性的情况下处理数据库时，您对在表列中使用文本标识符有何看法？

Question

哪种表结构被认为是更好的规范化？

例如

注意:idType 表示评论发生在哪个事物上，而 subjectid 是评论发生的项目的 id。

使用 idType 作为 subjectid 的文本命名标识符。

commentid ---- subjectid ----- idType--------------------------------------1                22            post2                26            photo3                84            reply4                36            post5                22            status

与此相比。

commentid ---- postid ----- photoid-----replyid-----------------------------------------------1                22          NULL        NULL2                NULL         56         NULL3                23          NULL        NULL4                NULL        NULL        555                26          NULL        NULL

我正在查看它们两个，我认为在第一个表中我无法将它与外键约束相关联 =((即，如果帖子或照片被删除，评论将被删除)，如第二个是可能的，您将如何处理类似的问题，请记住数据库将需要扩展加类时间并且数据完整性也很重要=)。

谢谢

Answer 1

第一个更规范化，如果稍微不完整。您可以采用多种方法，最简单的(严格来说，最“正确”的)将需要两个表，并具有明显的 FK 约束。

commentid ---- subjectid ----- idType
--------------------------------------
1                22            post
2                26            photo
3                84            reply
4                36            post
5                22            status

idType
------
post
photo
reply
status

如果您愿意，可以使用 char(1) 或类似的方法来减少 varchar 对键/索引长度的影响，或者如果您打算使用 ORM，则可以方便地与 ORM 一起使用。 NULL 总是很麻烦，如果您开始看到它们出现在您的设计中，那么如果您能找到一种方便的方法来消除它们，您会过得更好。

第二种方法是我在处理超过 1 亿行时更喜欢的方法:

commentid ---- subjectid
------------------------
1                22    
2                26     
3                84     
4                36     
5                22     

postIds ---- subjectid
----------------------
1                22   
4                36   

photoIds ---- subjectid
-----------------------
2                26    

replyIds ---- subjectid
-----------------------
3                84    

statusIds ---- subjectid
------------------------
5                22     

当然还有(稍微非规范化的)混合方法，我广泛使用大型数据集，因为它们往往很脏。只需为预定义的 idType 提供特化表，但在 commentId 表上保留一个临时的 idType 列。

请注意，即使是混合方法也只需要非规范化表空间的两倍；并通过 idType 提供简单的查询限制。然而，完整性约束不是直截了当的，它是对类型表的派生 UNION 的 FK 约束。我的一般方法是在混合表或等效的可更新 View 上使用触发器，将更新传播到正确的子类型表。

简单方法和更复杂的子类型表方法都有效；仍然，对于大多数用途，KISS 适用，所以我怀疑您应该只引入一个 ID_TYPES 表，相关的 FK，然后完成它。