blare, подумайте, как Вы их привязывать будете. В таблице photo_comments будет photo_id, в group_comments — group_id. Разный набор свойств — разные сущности. Создавать монстро-сущность сразу с тремя полями — плохая идея.
Mixei4, это очень плохой совет. Не надо сущность в месиво превращать.
Особенно замечательно будет со временем дампить и восстанавливать эту разбухшую таблицу с перемешанными ID.
Ну и кроме ID могут вполне возникнуть и другие различающиесь свойства.
Это не столько совет, сколько мысль о том «Как их привязывать».
Не понял проблемы с дампом и восстановлением таблицы. ID и у тех трёх таблиц будут в общем то не по порядку :) Да, она будет в 3 раза больше, но зато одна…
В случае изменения таблицы комментариев, редактировать надо только одну таблицу.
Например, добавляется возможность редактирования комментариев, надо добавить поле «время редактирования». Мы меняем один раз в одной таблице и всё. Не надо это делать в каждой таблице и вспоминать где ещё у нас хранятся комментарии.
Я вижу выгоду в уменьшении количества таблиц, в данном случае вместо 3 -1, к примеру если кроме комментариев добавить еще фотографии, то вместо еще 3 -1, таблицу жалоб на комментарии, вместо 3 — 1, таблицу рейтингов комментариев, вместо 3 -1, таблицу прикрепленных файлов к комментариям, вместо 3 — 1.
Итого вместо 15 таблиц — 5.
blare, так а какая выгода то кроме цифры количества таблиц? Можно сделать гипер-таблицу ENTITY и она будет одна :) Я понимаю там JOINы уменьшить, а слепить всё в одну таблицу… Ничего, кроме монструозной таблицы и путаницы в коде это не даст.
А чем плохо добавление отдельной таблицы вместо эфемерного «типа»? В общем, все Ваши аргументы сводятся к уменьшению цифры количества таблиц, хотя ничего плохого в количестве таблиц нет (это Вы просто не видели, сколько «таблиц» в NoSQL решениях :))
Я свои аргументы привёл — решать Вам, спорить не о чем. Ну ещё могу порекомендовать почитать о нормализации данных.
Чем неудобны три таблицы — потом запаришься осуществлять кейс поиска по комментарию. В какой из трех таблиц лежит нужный комментарий с текстом «Я и моя подруга Маша»? Все три нужно будет обходить. А это ненужное усложнение кода.
Чего внешнего ключа-то бояться? Целостность проверяется средствами БД.
Насчет отношений. Их можно вынести в отдельные таблицы, чтобы не городить лишних столбцов. А енум бы их адресовал.
Для каждой сущности типа фотка или пользователь нужен столбец в таблице комментариев (comments). Столбец будет представлять отношение между этими сущностями.Но вместо столбца можно завести отдельную таблицу, например photo_comments, а в таблице comments иметь поле, которая говорит нам, к какой таблице обращаться за отношением.
Это дает большую гибкость, например возможность связи не 1:N, а N:N, плюс общую структуру комментария мы инкапсулируем в отдельной таблице.
В постгресе же есть наследование таблиц!
Можно сделать одну пустую без поля привязки к entity id, а от неё отнаследовать три непустых более специфичных.
Не скажу за другие СУБД, но в MySQL использование ENUM вообще считается плохой практикой, т.к. данный тип допускает вставку элементов, которые не входят в перечисление (им будет присвоен индекс 0).
Если не хотите нарушать целостность данных, то однозначно делайте 3 разные таблицы с внешними ключами.
Средний
