mysql - 简单的数据库设计问题

Question

这可能是一个非常愚蠢的问题，但我只是不确定在以下场景中哪种解决方案是最优雅和最好(性能最高)的方法。

我有下表:

客户、公司、仪表、读数

该行上方的所有表都应该链接到“评论”表的一条或多条记录。哪种方式是模拟这种关系的最佳方式？

我在这里看到两种解决方案:

1.) 使用 m:n 关系:CustomerComment、CompanyComment 等 -> 以后易于扩展，但需要很多新表2.) 使用 1:n 关系:注释表有一个用于上面表的 PK 的字段(Customer_id、Company_id，...) -> 最小表方法，但“更难”扩展，因为我必须添加一个新的每当有一个新表需要有评论时，将字段添加到评论表

目标是一个模块化应用程序，它可能有也可能没有这四个表中的任何一个。

哪一个更好 - 还是还有更多？

谢谢!

Answer 1

这是使用整数作为主键的问题。您有一些可以使用的解决方案。

客户、公司、仪表、读数的任何给定行的真正唯一 ID 是 UUID。也许由于数据库设计的原因，主键必须是整数，但这没关系。这意味着如果您的系统中有新类型，您永远不必向 COMMENTS 表添加字段。它将始终通过类型 ID 进行引用。

您的表格可能如下所示:

CUSTOMER
   ID UUID

COMPANY
   ID UUID

METER
   ID UUID

COMMENTS
   ID
   RELATED_TO UUID
   COMMENT TEXT

现在您可以将注释附加到任何具有唯一 ID 的表格。

如果你想支持引用约束

OBJECT 是一个表，其中包含系统中所有数据的所有 ID。我们真正开始构建一个系统，您可以在其中将任何评论与您想要的任何内容关联起来。这可能不适合您的设计。

OBJECT
   ID UUID 

CUSTOMER
   ID UUID
   FOREIGN_KEY (ID) REFERENCES OBJECT(ID) ON DELETE CASCADE

COMPANY
   ID UUID
   FOREIGN_KEY (ID) REFERENCES OBJECT(ID) ON DELETE CASCADE

METER
   ID UUID
   FOREIGN_KEY (ID) REFERENCES OBJECT(ID) ON DELETE CASCADE

COMMENTS
   ID
   RELATED_TO UUID
   COMMENT TEXT
   FOREIGN_KEY (RELATED_TO) REFERENCES OBJECT(ID) ON DELETE CASCADE

这使设计变得复杂，以确保您不需要为系统中的每个新类型添加 2 个表。每个设计都有牺牲。在此例中，您对每个条目(无论是公司、客户还是仪表)说，我需要在对象表中关联一个 ID，以便在其上放置外键，从而使事情变得复杂。