Структура базы данных, один большой объект для нескольких объектов

Question

Предположим, что у меня есть веб-сайт магазина, где пользователь может оставлять комментарии о любом продукте.

Предположим, что у меня есть таблицы (сущности) в базе данных моего сайта: пусть это будут «Обувь», «Шляпы» и «Коньки». Я не хочу создавать отдельные таблицы комментариев для каждой сущности (например, «shoes_comments», «hats_comments», «skates_comments»). Моя идея - как-то хранить все комментарии в одной большой таблице.

Один из способов сделать это, что я думал, это создать таблицу:

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

и как флаг для каждого объекта, который может иметь комментарии.

Затем, когда я хочу, чтобы получить комментарии для некоторого продукта ВЫБОР запрос будет выглядеть так:

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

Это эффективный способ для реализации базы данных для необходимой функциональности? Какие еще способы я могу сделать это?>

Answer 1

Я бы рекомендовал вам сделать одну таблицу для комментариев и использовать внешний ключ других таблиц в таблице комментариев.

Answer 2

Извините, это кажется странным.

У вас действительно есть отдельная таблица для каждого типа продукта? Не имеют ли они общих полей (например, имя, описание, цена, изображение продукта и т. Д.)?

Моя рекомендация, как для таблиц: product для общих полей, comments с внешним ключом к product но без hasX колонн, hat только с полями, которые являются специфическими для линии шляпы продукта. Первичным ключом в hat является либо product ПК, либо индивидуальное уникальное значение (тогда вам понадобится дополнительное поле для внешнего ключа до product).

Answer 3

«нормированный» способ сделать это, чтобы добавить еще один объект (скажем, «Продукт»), который объединяет все характеристики, общие для обуви, головных уборов и скатов (включая комментарии)

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

Помимо соображений производительности , недостатком здесь является то, что в модели данных нет ничего, что препятствовало тому, чтобы строка в Product указывала как строка в Shoe, так и одна в Hat.

Есть и другие альтернативы (каждый из них с перками & недостатки) - вы можете прочитать что-то о «стратегиях наследования jpa» - вы найдете статьи, посвященные Java, которые обсуждают вашу проблему (просто игнорируйте java babbling и прочитайте остальное)

Лично я часто заканчиваю тем, что использовал единую таблицу для всех объектов в иерархии (обувь, шляпы и коньки в нашем случае) и жертвуя ограничениями на алтаре производительности и простоты (например: не null в поле обязательное для обуви, но не для шляп и коньков).