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

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

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

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

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

Спасибо

Ответ 1

Общее правило. Легче перейти от нормализованного к денормализованному, чем наоборот.

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

Ответ 2

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

Что касается безопасности: для плоского подхода вам потребуется написать много команд create/drop table, alter table etc, т.е. намного больше кода и намного больше ошибок.

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

То, как я бы справился с этим, - использовать нормализованную расширяемую таблицу "Свойство", например, ниже:

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

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

Ответ 7

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

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