Sql 数据库结构，一个大实体对应多个实体

假设我有一个商店网站，用户可以在那里对任何产品发表评论

假设我的网站数据库中有表（实体）：让它成为“鞋”、“帽”和“溜冰鞋”。 我不想为每个实体创建单独的“注释”表（如“shoes\u comments”、“hats\u comments”、“skates\u comments”）。 我的想法是以某种方式将所有评论存储在一个大表中

我想到的一种方法是创建一个表：

table (comments): 
ID (int, Primary Key), 
comment (text),  
Product_id (int), 
isSkates (boolean), 
isShoes (boolean), 
isHats (boolean) 

以及每个可能有注释的实体的like标志

然后，当我想获取某些产品的评论时，SELECT查询将如下所示：

SELECT comment 
FROM comments, ___SOMETABLE___
WHERE ____SOMEFLAG____ = TRUE 
  AND ___SOMETABLE___.ID = comments.Product_id

这是实现数据库所需功能的有效方法吗？

---

还有什么其他方法可以做到这一点呢？>

我建议您为注释创建一个表，并在注释表中使用其他表的外键。

对不起，这感觉很奇怪

是否每种产品类型都有一个单独的表格？它们是否有公共字段（例如名称、描述、价格、产品图像等）

对于表格，我的建议是：

product

对于公共字段，

comments

带有外键的

product

但没有

hasX

列，

hat

只带有特定于hat产品线的字段。

hat

中的主键要么是

产品

主键，要么是一个单独的唯一值（那么您需要为

产品

的外键添加一个额外的字段）。

实现这一点的“规范化”方法是再添加一个实体（例如，“产品”），将鞋、帽子和溜冰鞋共有的所有特征（包括注释）进行分组

除了性能方面的考虑之外，这里的缺点是数据模型中没有任何内容阻止产品中的一行同时被Shoe中的一行和Hat中的一行引用

还有其他的选择（每个都有特权和缺陷）-你可能想读一些关于“jpa继承策略”的文章-你会找到讨论同样问题的java特定文章（只需忽略java的唠叨，阅读其余部分）

---

就我个人而言，我经常使用一个表来表示层次结构中的所有实体（在我们的例子中是鞋子、帽子和溜冰鞋），并牺牲性能和简单性上的约束（例如：在鞋子必须使用但帽子和溜冰鞋不能使用的字段中不能为null）。

我的想法有些不同。正如我所理解的，您的想法是：为每个实体表的全局注释表添加一个外键。好的，我想对于一种类型的产品，这并不难。但在我的情况下，我有完全独立的实体（假设：组织、员工、技术设备），我需要为它们存储评论……好吧，我被你的例子误导了，对不起。不过，如果您愿意稍微改变规则，您只需要一个

注释
表。我想，对于每个有注释的实体，您不希望在
comment
中有一个外键列。如果您没有实际的外键列，但在
comment
中有一列声明为
parent\u id
，该怎么办？我想从
X
到
comment
的关系可以是单向的？另一种选择是为每个
X
到
注释
都有一个联接表，例如
shoe\u X\u comment
，
hat\u X\u comment
。在我将创建表“COMMENTABLE”并从实体表（hat，shoes，skates）以1:1的关系将它们连接到它的情况下，这会起作用吗？是的想法！在开始之前，你会考虑表演…例如：要添加一个新的Shoe，您需要两个insert语句（1个用于Commentable，1个用于Shoe）-如果您有注释的id，并且希望导航到其所有者实体，您需要（可能有几个）union子句，因为您事先不知道该实体在哪个表中（可能是Shoe、Hat或Skate）…这里真正的问题是E/R不做继承-人们可以模拟它（如在3 JPA策略中），但他必须接受一些折衷
              +-- 0..1 [Shoe]
              |
[Product] 1 --+-- 0..1 [Hat]
    1         |
    |         +-- 0..1 [Skate]
    *
[Comment]