Ребят, как посоветуете разрулить такую ситуацию Надо добавить в приложение чат,

а точнее комменты
Комментарии будут как виджет который используется на двух разных страницах к разным вещам

Грубо говоря в таблице комментов должен быть внешний ключ на запись из одной или другой таблицы, это то, к чему привязан комментарий, (обобщим и например 1 таблица это видео а другая какая-то галерея и у них обоих есть комментарии)

Есть идея сделать 3ю таблицу в которой два поля
1 - айди
2 - число по которому можно определить для какой таблицы выше указанное айди является типа внешним ключом

Но мне кажется что то, что для самой БД теряется явная связь - является проблемой

Это нормальное решение? или стоит подумать еще, либо же кто-то может подсказать?
Если нормальное, то как в итоге таблицу то эту назвать?

Видел такое решение на практике. Расшифровка значений кодов из пары десятков таблиц хранилась в одной таблице с полями имя_таблицы; код; текстовая расшифровка значения кода.

Понял, спасибо

Но ради только двух таблиц стоит-ли так делать?

Так я вот и думаю, а как еще иначе? Ну как минимум лид мне сказал попробовать сделать примерно так Просто еще вдруг в будущем может появится 3й источник комментов

Если сделать по своей таблице на каждый вид контента то есть шанс, что будет быстрее и можно предусмотреть специфические для контента поля, например сохранить кадр из видео, к которому относится коммент. С другой стороны одна таблица - проще.

К каким именно разным вещам?

Нормальное решение тут р наследование всего, что имеет комментарии от общего базового класса "комментируемое" и ссылка комментария на него (базовый класс)

Это еботня

Если считаете, что отсутствие referential integrity constraint в базе является проблемой -- не делайте. Сделайте по одному полю на каждую таблицу (другое поле будет null в каждой записи, соответственно). В postgres, например, это почти ничего не стоит -- в большынстве других СУБД, думаю, тожэ. С другой стороны -- я часто не вставляю имеющиеся по бизнес-логике refrential integrity constraints в схему СУБД. Поскольку мне, в принцыпе, например, часто лучшэ пусть ошыбочный код приложэния отработает -- а несостыковки потом выяснятся при регулярном housekeeping в спокойной обстановке, чем вот это всё fail early и разбирать проблемы когда они только проявятся в более авральном режыме. Но это такое, не то, чтобы я это прямо советовал. В общем, я хочу сказать -- что более правильно с теоретической позицыи сделать нескольк полей с правильным constraints, там и с типом данных меньшэ проблем, и с внесением логики в схему. Но и одно поле и case вполне сработает.

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

Наследование в любой СУБД реляционной можно делать. man hibernate

Фу, я думал, тут приличные люди собрались -- а мне ORMами перед носом трясут!

Я тебе не предлагаю пользоваться ORM, я тебе предлагаю прочитать там как реализуется наследование

Да мне плевать.

А ну ок

То есть я могу и на ленте машыны Тьюринга реализовать наследование -- и знаю как оно реализуется на линейной однородной байт-адресуемой памяти произвольного доступа (притом в нескольких вариантах -- стандарт C++, словари Lua и пр.). Это, типа, немного не новость, что можно его реализовать.

+

Наследование можно в чем угодно сделать, - поинт в том, что его вообще обычно не надо делать. И в этом смысле идея Стоунбрейкера про базу с наследованием оказалась не особо хорошей. А ORM тут вообще не при чем

Ну тебе не надо -так и ок. А я делал, и делаю, очень помогает в проектировании нормальных систем: ты экономишь кучу усилий на реализацию ПО только один раз. Рекомендую.

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

Так это,ты как идентификаторы таблиц-то различать будешь? Вот есть content_id = 42 , как узнать, из какой таблицы это ?

Один столбец это contentId и второй contentIdFrom. И не надо никаких третьих таблиц. В идеале конечно contentId должен ссылаться на одну таблицу, а не на несколько, но в постановке проблемы таблиц уже две и может быть больше.

Ну ок... Доменная целостность нарушена... Вся статистика по столбцу всмятку... хинты писать в каждый запрос... Индексы ... Индексы конечно работать будут. Не так и плохо на самом деле.

Ну кто же спорит, да ссылочность будет логическая в зависимости от столбца contentIdFrom. Правильно contentId держать в одной таблице, а в текущем варианте постановки проблемы два столбца в таблице комментариев является быстрым, простым решением, а статистику можно и по двум столбцам сделать.