Enum или несколько таблиц?

Question

[blare]

Добрый день!



Задался таким вопросом, вот к примеру, возьмем тот же Вконтакте. У нас в бд есть несколько сущностей, к примеру стена, фотография, группа.



Нужно сделать комментарии к ним. Какой бы вы способ выбрали:



1. Сделать единую таблицу комментариев, в которой будет поле enum с перечислениями 'user', 'photo', 'group'.



2. Сделать три разные таблицы user_comments, photo_comments, group_comments

Answer 1

[EugeneOZ]

Три разные таблицы, конечно. Разные сущности нужно хранить в разных таблицах.

Comments

[Павел Загребелин]

чем комментарии к фотке отличаются от комментариев к группе?

[blare]

Комментарий это одна сущность же, разве нет?

[EugeneOZ]

blare, подумайте, как Вы их привязывать будете. В таблице photo_comments будет photo_id, в group_comments — group_id. Разный набор свойств — разные сущности. Создавать монстро-сущность сразу с тремя полями — плохая идея.

[MiXei4]

Можно завести одно поле entity_id. Какая это конкретно сущность понятно из того самого поля enum.

[EugeneOZ]

Mixei4, это очень плохой совет. Не надо сущность в месиво превращать.
Особенно замечательно будет со временем дампить и восстанавливать эту разбухшую таблицу с перемешанными ID.
Ну и кроме ID могут вполне возникнуть и другие различающиесь свойства.

[MiXei4]

Это не столько совет, сколько мысль о том «Как их привязывать».
Не понял проблемы с дампом и восстановлением таблицы. ID и у тех трёх таблиц будут в общем то не по порядку :) Да, она будет в 3 раза больше, но зато одна…

[EugeneOZ]

MiXei4, какую выгоду даёт это «зато»?

[MiXei4]

В случае изменения таблицы комментариев, редактировать надо только одну таблицу.
Например, добавляется возможность редактирования комментариев, надо добавить поле «время редактирования». Мы меняем один раз в одной таблице и всё. Не надо это делать в каждой таблице и вспоминать где ещё у нас хранятся комментарии.

[blare]

Я вижу выгоду в уменьшении количества таблиц, в данном случае вместо 3 -1, к примеру если кроме комментариев добавить еще фотографии, то вместо еще 3 -1, таблицу жалоб на комментарии, вместо 3 — 1, таблицу рейтингов комментариев, вместо 3 -1, таблицу прикрепленных файлов к комментариям, вместо 3 — 1.
Итого вместо 15 таблиц — 5.

[EugeneOZ]

blare, так а какая выгода то кроме цифры количества таблиц? Можно сделать гипер-таблицу ENTITY и она будет одна :) Я понимаю там JOINы уменьшить, а слепить всё в одну таблицу… Ничего, кроме монструозной таблицы и путаницы в коде это не даст.

[blare]

Универсальность, в случае появления еще одной сущности надо будет добавить тип, вместо нескольких таблиц.

[EugeneOZ]

А чем плохо добавление отдельной таблицы вместо эфемерного «типа»? В общем, все Ваши аргументы сводятся к уменьшению цифры количества таблиц, хотя ничего плохого в количестве таблиц нет (это Вы просто не видели, сколько «таблиц» в NoSQL решениях :))
Я свои аргументы привёл — решать Вам, спорить не о чем. Ну ещё могу порекомендовать почитать о нормализации данных.

Answer 2

[gleb_kudr]

Чем неудобны три таблицы — потом запаришься осуществлять кейс поиска по комментарию. В какой из трех таблиц лежит нужный комментарий с текстом «Я и моя подруга Маша»? Все три нужно будет обходить. А это ненужное усложнение кода.
Чего внешнего ключа-то бояться? Целостность проверяется средствами БД.

Насчет отношений. Их можно вынести в отдельные таблицы, чтобы не городить лишних столбцов. А енум бы их адресовал.

Comments

[blare]

Насчет отношений. Их можно вынести в отдельные таблицы, чтобы не городить лишних столбцов.

Что вы имеете ввиду?

[gleb_kudr]

Для каждой сущности типа фотка или пользователь нужен столбец в таблице комментариев (comments). Столбец будет представлять отношение между этими сущностями.Но вместо столбца можно завести отдельную таблицу, например photo_comments, а в таблице comments иметь поле, которая говорит нам, к какой таблице обращаться за отношением.
Это дает большую гибкость, например возможность связи не 1:N, а N:N, плюс общую структуру комментария мы инкапсулируем в отдельной таблице.

Answer 3

[basht]

В постгресе же есть наследование таблиц!
Можно сделать одну пустую без поля привязки к entity id, а от неё отнаследовать три непустых более специфичных.

Comments

[blare]

Спасибо, интересная функция.

Answer 4

[AlexeyVD]

Не скажу за другие СУБД, но в MySQL использование ENUM вообще считается плохой практикой, т.к. данный тип допускает вставку элементов, которые не входят в перечисление (им будет присвоен индекс 0).
Если не хотите нарушать целостность данных, то однозначно делайте 3 разные таблицы с внешними ключами.

Answer 5

[StrangeAttractor]

Я бы вынес все комментарии ко всему в отдельную таблицу вообще, а потом так или иначе связывал её с комментируемым.

Comments

[blare]

Да, все же я так и сделал, только вот думаю добавлять ли поле в каждую таблицу, чтоб обеспечить внешний ключ по двум полям или нет)