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

Question

假设我有一个商店网站，用户可以在其中留下有关任何产品的 cmets。

假设我的网站数据库中有表格（实体）：让它成为“鞋子”、“帽子”和“溜冰鞋”。 我不想为每个实体创建单独的“cmets”表（如“shoes_cmets”、“hats_cmets”、“skates_cmets”）。 我的想法是以某种方式将所有 cmets 存储在一张大表中。

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

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

为每个可能拥有 cmets 的实体设置类似标志。

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

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

这是为所需功能实现数据库的有效方法吗？ 我还有什么其他方法可以做到这一点？>

Answer 1

抱歉，这感觉很奇怪。

您是否确实为每种产品类型提供了一个单独的表格？他们没有共同的领域（例如名称、描述、价格、产品图片等）吗？

我对表格的建议：product 用于公共字段，comments 具有外键到 product 但没有 hasX 列，hat 仅具有特定于帽子产品线的字段。 hat 中的主键要么是 product PK 要么是一个单独的唯一值（那么你需要一个额外的字段作为 product 的外键）。

Answer 2

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

Answer 3

执行此操作的“规范化”方法是再添加一个实体（例如，“产品”），将鞋子、帽子和溜冰鞋（包括 cmets）的所有常见特征分组

              +-- 0..1 [Shoe]
              |
[Product] 1 --+-- 0..1 [Hat]
    1         |
    |         +-- 0..1 [Skate]
    *
[Comment]

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

还有其他替代方案（每个都有优点和缺陷）-您可能想阅读有关“jpa 继承策略”的内容-您会找到讨论相同问题的特定于 java 的文章（只需忽略 java babbling 并阅读其余的）

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