Полная целостность БД (в 5 раз больше таблиц) по сравнению с имитацией концепций в rdbms
Так что у меня есть этот ночной кошмар (RDBMS) . Я задавал здесь много вопросов, но ни на один из них не было ответа о том, как имитировать оо понятия в rdbms...
Многие веб-сайты (форумы, социальные сети и т. Д.) Имеют множество функций для размещенного контента.
У них могут быть комментарии, лайки, акции, звезды и т.д...
Предполагая, что может быть несколько типов сообщений (обычное сообщение, комментарий, фотография, вопрос) и некоторые типы сообщений не могут иметь все функции (например, скажем, только звезды и комментарии), довольно сложно решить, какой путь выбрать....
Я могу идти:
на дороге, создав идентификатор объекта и тип объекта для каждого сообщения (на этот идентификатор объекта будут ссылаться в каждой таблице сообщений, а функция также будет ссылаться на идентификатор объекта). Также необходимо, чтобы тип сущности вызывал некоторые триггеры целостности, например, сущность комментария может иметь подобную функцию, но не функцию комментария. Это поле типа сущности будет ночным, если потребуется добавить больше функций для сообщений (потребуется добавить некоторые новые типы сущностей). И это просто беспорядок для целостности данных.
или в 5 раз больше таблиц БД. Под этим я подразумеваю разработку таблиц функций для каждого типа таблицы сообщений. Это потребует большего количества соединений, более длинных запросов, но, по крайней мере, я знаю, что у меня не будет проблем с целостностью или масштабируемостью данных.
Я должен использовать rdbms, не могу пойти по пути oodbms или по графику.
Что вы выберете из этих двух типов дизайна? Или как бы вы спроектировали это лучше?
1 ответ
Что вы выберете из этих двух типов дизайна? Или как бы вы спроектировали это лучше?
Сосредоточьтесь на OO на вашем языке приложения. СУБД плохо подходит для концепций ОО. Вместо этого используйте NULL и т. Д., А не пытайтесь изобрести таблицы подклассов.
(Ладно, может быть, мой ответ хромает. Но он выводит этого старичка из "Без ответа")