Недостатки хранения всех «вещей» в центральном столе

Question

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

например. все (сообщения блога, страницы, изображения, события и т. д.) хранится в одной таблице и рассматривается как сообщение.

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

мы рассматриваем возможность разработки нашего нового проекта таким образом. Это не совсем CMS, но мы планируем постепенно добавлять к ней модули. Допустим, изначально будут только посты и изображения, на которые можно оставлять комментарии. Позже мы можем добавить видео, которые также будут иметь функцию комментирования.

Каковы недостатки этого подхода? и будет ли оно работать для таких требований, как у нас?

Спасибо

Answer 1

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

Это означает, что будет много конфликтов блокировок, интенсивного переиндексации и т. Д.

Чтобы немного это смягчить, вы можете рассмотреть возможность разделения «основной таблицы» на ряд не очень основных таблиц.

Скажем, у вас будет одна основная таблица для "Сообщений" (возможно, уточненная с помощью метаданных или подтаблиц для определенных типов сообщений, таких как Sticky, Announcement, Shoutbox, Private ...)

Oneглавная таблица для изображений (возможно, уточнена для gif, jpegs и т. д.)

одна главная таблица для видео ...

Если это пользовательское приложение (и оно не должнобыть «бесконечно настраиваемым», как CMS или платформа Portal) Я думаю, что этот вид разделения приемлем и может обеспечить лучшую производительность (если вы ожидаете иметь большие объемы данных).

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

Answer 2

Простота и расширяемость действительно часто являются привлекательными аспектами значения атрибута и (как вы говорите) приближаются к «единой таблице вещей».

Здесь нет 100% правильного ответа здесь - в зависимости от ваших целей производительности / пропускной способности и потребностей в расширяемости, этот подход может работать и для вас.

Однако в большинстве случаев, когда вы знаете, какие типы данных вы будете хранить, обычно в ваших интересах смоделировать отдельные сущности в их собственных таблицах и соответствующим образом связать данные. СУБД создавались и совершенствовались на протяжении десятилетий для удовлетворения этого варианта использования и простого использования таблиц в качестве общих дамповых баз, как правило, не дает вам каких-либо явных преимуществ, за исключением действия по отсрочке неизбежной необходимости правильно моделировать ваши данные. Кроме того, когда вы сводите все в одну таблицу, вы заставляете пользователей вне самого вашего приложения (если у вас есть, например, создатели отчетов) бороться с вашей «моделью в модели», что может просто расстроить людей, когда они писать запросы и т. д. И вы погрузитесь в свой наименьший общий знаменатель - если вы хотите оптимизировать запросы о типе X и у вас есть типы Y и Z в той же таблице в массовом порядке, они повлияют на производительность при запросе X.

Опять же, для ясности, есть очевидное преимущество в подходах метаданных стиля имя / значение "все вещи в одной таблице". Я использовал их сам и отказался от моделирования по тем же причинам. Тем не менее, я советую ограничиться временем, когда вам действительно нужно это сделать (т.е. вам нужно что-то реализовать, прежде чем вы сможете правильно смоделировать пространство вещей, которое вам понадобится). Чаще всего я делаю это, когда создаю прототипы сложных систем, и мне нужно что-то запустить раньше, чем позже.