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

Question

Suppose that I have a store-website where user can leave comments about any product.

Suppose that I have tables(entities) in my website database: let it be 'Shoes', 'Hats' and 'Skates'. I don't want to create separate "comments" table for every entity (like 'shoes_comments', 'hats_comments', 'skates_comments'). My idea is to somehow store all the comments in one big table.

One way to do this, that I thought of, is to create a table:

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

and like flag for every entity that could have comments.

Then when I want to get comments for some product the SELECT query would look like:

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

Is this an efficient way to implement database for needed functionality? What other ways i can do this?>

Answer 1

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

Answer 2

Sorry, this feels odd.

Do you indeed have one separate table for each product type? Don't they have common fields (eg name, description, price, product image, etc.)?

My recommendation as for tables: product for common fields, comments with foreign key to product but no hasX columns, hat with only the fields that are specific to the hat product line. The primary key in hat is either the product PK or an individual unique value (then you'd need an extra field for the foreign key to product ).

Answer 3

The "normalized" way to do this is to add one more entity (say, "Product") that groups all characteristics common to shoes, hats and skates (including comments)

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

Besides performance considerations, the drawback here is that there is nothing in the data model preventing a row in Product to be referenced both by a row in Shoe and one in Hat.

There are other alternatives too (each with perks & flaws) - you might want to read something about "jpa inheritance strategies" - you'll find java-specific articles that discuss your same issue (just ignore the java babbling and read the rest)

Personally, I often end up using a single table for all entities in a hierarchy (shoes, hats and skates in our case) and sacrificing constraints on the altar of performance and simplicity (eg: not null in a field that is mandatory for shoes but not for hats and skates).