Является ли это «правильным» проектом базы данных?

Question

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

Старая версия БД имела общую структуру, как это:

TABLE ENTITY 
(
    ENTITY_ID, 
    STANDARD_PROPERTY_1, 
    STANDARD_PROPERTY_2, 
    STANDARD_PROPERTY_3, 
    ... 
) 

TABLE ENTITY_PROPERTIES 
(
    ENTITY_ID, 
    PROPERTY_KEY, 
    PROPERTY_VALUE 
) 

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

Новая версия БД InstEd имеет структуру, как это:

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, 
    ... 
) 

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

Итак, мой вопрос: это правильный способ проектирования структуры БД? Это единственный способ до «увеличить производительность»? Старая структура требовала много соединений или подсетов, но эта структура не кажется мне очень умной (или даже правильной) ...

Answer 1

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

I полностью не согласны с этим.

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

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

Или ждать в течение дня вы бежите в максимальное количество таблиц в базе данных :-)

Другие предложили совершенно разные магазины. Это вполне жизнеспособная возможность, и если бы у меня не было существующей структуры базы данных, я бы тоже ее рассматривал. Тем не менее, я не вижу причин, почему эта структура не может вписаться в СУБД. Я видел, как это делалось практически во всех крупных приложениях, над которыми я работал.Интересно, что все они прошли по аналогичным маршрутам, и все они были в основном «успешными» реализациями.

Answer 2

Я считаю, что создание новой таблицы для каждого объекта для хранения свойств - плохой дизайн так как вы могли бы дополнить базу данных таблицами. Единственным просом для применения второго метода было бы то, что вы не проходите через все избыточные строки, которые не применяются к выбранному объекту. Однако использование индексов в вашей базе данных в исходной таблице ENTITY_PROPERTIES может значительно помочь в производительности.

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

Answer 3

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

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

Если бы я был вами, я бы либо исправить количество настраиваемых свойств, либо придерживаться старой системы.

Answer 4

Нет, это не так. Это ужасно.

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

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

Рассмотрим это:

• Вы теряете все безопасность типов, как вы должны хранить все значения в столбце «PROPERTY_VALUE»
• В зависимости от ваших пользователей, вы могли бы их изменить схему заранее, а затем пусть они запускают какое-то пакетное задание на обновление базы данных, поэтому, по крайней мере, все свойства будут объявлены в правильном типе данных. Кроме того, вы можете потерять объект entity_id/key.
• Отъезд: http://en.wikipedia.org/wiki/Inner-platform_effect. Это, конечно, пахнет этим
• Возможно, СУБД не подходит для вашего приложения. Подумайте о том, как использовать хранилище на основе ключа/значения, например MongoDB или другую базу данных NoSQL. (http://nosql-database.org/)

Answer 5

Там нет «правильного» способа создать базу данных - я не в курсе общепризнанного набора отличных от известных "normal form" теории стандартов; многие проекты баз данных игнорируют этот стандарт по соображениям производительности.

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

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

Я предполагаю, что новый проект не будет ощутимо быстрее для запросов, как «найти STANDARD_PROPERTY_1 от лица, где STANDARD_PROPERTY_1 =„банан“.

Я предполагаю, что это не будет ощутимо быстрее при получении всех свойств для данного объекта, на самом деле он может быть немного медленнее, потому что вместо единственного присоединения к ENTITY_PROPERTIES новый дизайн требует объединения к нескольким таблицам.Вы будете возвращать «разреженные» результаты - по-видимому, не все объекты будут иметь значения в столбцах property_n во всех таблицах ENTITY_PROPERTIES_n.

Если новый дизайн может быть значительно быстрее, вам понадобится предложение where where. Например, если найти объект, в котором пользовательское свойство 1 истинно, пользовательское свойство 2 является бананом, а пользовательское свойство 3 не находится («kylie», «pussycat dolls», «giraffe»), скорее всего, быстрее (если возможно) укажите столбцы в таблицах ENTITY_PROPERTIES_n вместо строк в таблице ENTITY_PROPERTIES. Вероятно.

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

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