Это «правильный» дизайн базы данных?
Я работаю с новой версией стороннего приложения. В этой версии структура базы данных изменена, говорят «для повышения производительности».
Старая версия БД имела общую структуру, подобную этой:
<code>TABLE ENTITY
(
ENTITY_ID,
STANDARD_PROPERTY_1,
STANDARD_PROPERTY_2,
STANDARD_PROPERTY_3,
...
)
TABLE ENTITY_PROPERTIES
(
ENTITY_ID,
PROPERTY_KEY,
PROPERTY_VALUE
)
</code>
поэтому у нас была основная таблица с полями для основных свойств и отдельная таблица для управления пользовательскими свойствами, добавленными пользователем.
Новая версия встроенной БД имеет такую структуру:
<code>TABLE ENTITY
(
ENTITY_ID,
STANDARD_PROPERTY_1,
STANDARD_PROPERTY_2,
STANDARD_PROPERTY_3,
...
)
TABLE ENTITY_PROPERTIES_n
(
ENTITY_ID_n,
CUSTOM_PROPERTY_1,
CUSTOM_PROPERTY_2,
CUSTOM_PROPERTY_3,
...
)
</code>
Итак, теперь, когда пользователь добавляет пользовательское свойство, новый столбец добавляется к текущемуENTITY_PROPERTY стол доmax number of columns (управляется приложением), затем создается новая таблица.
Итак, мой вопрос: это правильный способ проектирования структуры БД? Это единственный способ"increase performances"? Старая структура требовала большого количества соединений или суб-выбора, но эта структура не кажется мне очень умной (или даже правильной) ...
Ответы на вопрос(5)
что создание новой таблицы для каждой сущности для хранения свойств - это плохой дизайн, так как в итоге вы можете заполнить базу данных таблицами. Единственным преимуществом применения второго метода будет то, что вы не просматриваете все лишние строки, которые не применяются к выбранному объекту. Однако использование индексов в вашей базе данных для исходной таблицы ENTITY_PROPERTIES может значительно повысить производительность.
Я бы лично придерживался вашего первоначального дизайна, применял индексы и позволял ядру базы данных определять лучшие методы для выбора данных, а не разделять каждое свойство сущности в новую таблицу.
ого набора стандартов, кроме известного& quot; нормальная форма & quot; теория; многие дизайны баз данных игнорируют этот стандарт по соображениям производительности.
Однако существуют способы оценки структуры базы данных - производительность, удобство обслуживания, разборчивость и т. Д. Довольно часто приходится обменивать их друг на друга; это то, что, по-видимому, делает ваше изменение - удобство торговли и понятность производительности.
Таким образом, лучший способ выяснить, был ли это хороший компромисс, это посмотреть, материализовался ли прирост производительности. Лучший способ выяснить это - создать предложенную схему, загрузить ее с репрезентативным набором данных и написать запросы, которые вам понадобятся для запуска в работе.
Я предполагаю, что новый дизайн не будет заметно быстрее для запросов типа "найти STANDARD_PROPERTY_1 от объекта, где STANDARD_PROPERTY_1 =" банан ".
Я предполагаю, что это не будет заметно быстрее при извлечении всех свойств для данного объекта; на самом деле это может быть немного медленнее, потому что вместо одного соединения с ENTITY_PROPERTIES новый дизайн требует объединения нескольких таблиц. Вы будете возвращать & quot; разреженные & quot; результаты - предположительно, не все объекты будут иметь значения в столбцах property_n во всех таблицах ENTITY_PROPERTIES_n.
Новый дизайн может быть значительно быстрее, когда вам нужен составной оператор where для пользовательских свойств. Например, обнаружение сущности, в которой настраиваемое свойство 1 является истинным, настраиваемое свойство 2 является банановым, а настраиваемое свойство 3 отсутствует в ("kylie", "pussycat dolls & amp; a, pos ;," giraffe ") - e` (возможно) быстрее, когда вы можете указать столбцы в таблицах ENTITY_PROPERTIES_n вместо строк в таблице ENTITY_PROPERTIES. Наверное.
Что касается ремонтопригодности - гадость. Ваш код доступа к базе данных теперь должен быть намного умнее, зная, какая таблица содержит какое свойство и сколько столбцов слишком много. Вероятность появления интересных ошибок высока - есть больше движущихся частей, и я не могу думать о каких-либо очевидных модульных тестах, чтобы убедиться, что логика доступа к базе данных работает.
Интеллектуальность - это еще одна проблема - этого решения нет у большинства разработчиков & apos; Это не стандартная модель. Старое решение довольно широко известно - его обычно называют «entity-attribute-value». Это становится серьезной проблемой для долгоживущих проектов, где вы не можете гарантировать, что оригинальная команда разработчиков будет находиться рядом.
что я знаю о базах данных (но я, конечно, не самый опытный), кажется, что это плохая идея сделать это в вашей базе данных. Если вы уже знаете, сколько максимальных пользовательских свойств может иметь пользователь, я бы сказал, что вам лучше установить в таблице число столбцов, равное этому значению.
С другой стороны, я не эксперт, но создание новых столбцов на лету - это не тот тип баз данных операций, как. Это принесет вам больше неприятностей, чем что-либо еще.
Если бы я был вами, я бы либо исправил количество пользовательских свойств, либо придерживался старой системы.
assumed (часто бездоказательно) "расход" объединения - это, в основном, превращение таблицы данных с большим количеством строк в таблицу с большим количеством столбцов. Как вы и предполагали, они столкнулись со своими собственными ограничениями, создавая новые таблицы, когда у них заканчиваются столбцы.
яcompletely не согласен с этим
Лично я придерживаюсь старой структуры и переоцениваю проблемы с производительностью. Это не означает, что старый способ является правильным, он просто немного лучше, чем «улучшение». на мой взгляд, и устраняет необходимость делать масштабную реинжиниринг таблиц базы данных и кода DAL.
Эти таблицы кажутся мне в основном статичными ...caching было бы еще лучшее улучшение производительности без искажения базы данных, и я хотел бы рассмотреть это в первую очередь. Сделайте "дорогой" извлеките один раз и вставьте его в память куда-нибудь, затем забудьте о своих проблемах (обратите внимание, я подчеркиваю необходимость управления кэшем, но статические данные - одни из самых простых в управлении).
Или дождитесь того дня, когда вы встретите максимальное количество таблиц в базе данных :-)
Другие предложили совершенно разные магазины. Это вполне жизнеспособная возможность, и если бы у меня не было существующей структуры базы данных, я бы тоже ее рассмотрел. Тем не менее, я не вижу причин, по которым эта структура не может вписаться в СУБД. Я видел, как это было сделано почти во всех масштабных приложениях, над которыми я работал. Интересно, что все они пошли внизsimilar маршрут и все они были в основном "успешными" Реализации.
until the max number of column (handled by application) is reached, then a new table is created.
Это предложение говорит обо всем. Ни при каких обстоятельствах приложение не должно динамически создавать таблицы. «Старый» подход также не идеален, но, поскольку у вас есть требование разрешить пользователям добавлять пользовательские свойства, оно должно быть таким.
Учти это:
You lose all type-safety as you have to store all values in the column "PROPERTY_VALUE" Depending on your users, you could have them change the schema beforehand and then let them run some kind of database update batch job, so at least all the properties would be declared in the right datatype. Also, you could lose the entity_id/key thing. Check out this: http://en.wikipedia.org/wiki/Inner-platform_effect. This certainly reeks of it Maybe a RDBMS isn't the right thing for your app. Consider using a key/value based store like MongoDB or another NoSQL database. (http://nosql-database.org/)