Должен ли я использовать плоские таблицы или нормализованную базу данных?

Question

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

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

Должен ли я поддерживать нормализацию базы данных со всем, объединенным в реляционные таблицы с внешними ключами (индексы и т. Д.), Или я должен строить плоские таблицы для каждой новой формы, которую создает пользователь?

Очевидно, что некоторые положительные моменты создания плоских таблиц - это разделение данных (безопасность) и скорость запросов. Но серьезно, сколько я получу от этого? Мне действительно не нужны 10000 таблиц, и я все время отбрасываю, изменяю и добавляю все, но если это будет лучше, чем я это сделаю ... Мне просто нужно внести свой вклад.

Спасибо

Answer 1

Правило большого пальца. Легче перейти от нормализованного к денормализованному, чем наоборот.

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

Answer 2

Изменение схемы во время работы редко является хорошей идеей. Вы хотите рассмотреть модель EAV (Entity-Attribute-Value).

Википедия имеет some very good info о плюсах и минусах, а также о деталях реализации. EAV следует избегать, когда это возможно, но для ситуаций, подобных вашим, с неизвестным количеством столбцов для каждой формы, EAV рассматривает.

Answer 3

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

Если вы действительно хотите пойти быстро, переключите схему в одну из баз данных с ключевыми значениями, например bigDB/couchDB и т. Д. Это полностью денормализованное и очень быстрое.

Answer 4

... в этом приложении пользователи смогут строить свои собственные формы с любым количеством полей ...

Хлоп! Тогда как вы могли бы , возможно, делать какие-либо нормализации, когда пользователи, в сущности, принимают решения по базе данных для вас.

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

Answer 5

Путь я бы справиться с этим, чтобы использовать нормированную, расширяемый «Property» таблицы, например, как показано ниже:

Table: FormProperty 
id: pk 
form_id: fk(Form) 
key: varchar(128) 
value: varchar(2048) 

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

Answer 6

Сохраните ваши данные в норме. Если вы правильно указали, вы не столкнетесь с проблемами производительности в течение очень долгого времени.

Что касается безопасности: при плоском подходе вам потребуется написать много таблиц создания/удаления, изменить таблицы и т. Д., Т. Е. Намного больше кода и намного больше ошибок.

Единственная причина иметь плоские файлы - это когда ваши пользователи могут напрямую подключаться к БД (вы все равно можете пойти на уровень безопасности на уровне строк). Но в этом случае вы действительно реализовав вариант PHPMyAdmin

Answer 7

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

Денормализованные == быстро вставляет, Ususally это используется когда есть много вставок (хранилища данных, которые собирают и записывают хронологические данные)