У меня есть веб-приложение, в котором я сейчас работаю, которое использует базу данных MySQL для внутреннего использования, и мне нужно знать, что лучше для моей ситуации, прежде чем продолжить.
Проще говоря, в этом приложении пользователи смогут создавать свои собственные формы с любыми числовыми полями (они решают), и сейчас я все это храню в нескольких таблицах, связанных внешними ключами. Мой друг говорит, что для того, чтобы "легко и быстро" было необходимо преобразовать каждую форму пользователя в плоскую таблицу, чтобы запрос данных из них оставался быстрым (в случае большого роста).
Должен ли я поддерживать нормализацию базы данных со всем, объединенным в реляционные таблицы с внешними ключами (индексы и т.д.), или мне нужно строить плоские таблицы для каждой новой формы, которую создает пользователь?
Очевидно, что некоторые положительные стороны создания плоских таблиц - это разделение данных (безопасность), и скорость запросов будет сокращена. Но серьезно, сколько я получу от этого? Мне действительно не нужны 10000 таблиц, и я все время отбрасываю, изменяю и добавляю все, но если это будет лучше, чем я это сделаю... Мне просто нужен какой-то ввод.
Спасибо
Общее правило. Легче перейти от нормализованного к денормализованному, чем наоборот.
Начните с разумного уровня нормализации базы данных (разумным я имею в виду читабельность, поддерживаемость и эффективность, но не преждевременно оптимизированную), а затем, если вы столкнетесь с проблемами производительности по мере роста, у вас есть возможность взглянуть на способы, при которых денормализация может повысить производительность.
Сохраняйте нормализацию данных. Если вы правильно указали, вы не столкнетесь с проблемами производительности в течение очень долгого времени.
Что касается безопасности: для плоского подхода вам потребуется написать много команд create/drop table, alter table etc, т.е. намного больше кода и намного больше ошибок.
Единственная причина иметь плоские файлы - это когда ваши пользователи могут напрямую подключаться к БД (вы все равно можете пойти на уровень безопасности на уровне строк). Но в этом случае вы действительно переопределяете вариант phpmyadmin
... в этом приложении пользователи смогут создавать свои собственные формы с любыми полями чисел...
Хлоп! Тогда как вы могли бы делать какие-либо нормализации, когда пользователи, в сущности, принимают решения по базе данных для вас.
Я думаю, вам нужно либо управлять им шаг за шагом, либо позволить вашему фрикционному флагом летать, и просто держать покупку оборудования, чтобы идти в ногу с трением, которое вы собираетесь получить, когда пользователи действительно начнут проникать в него. Например, посмотрите, что происходит, когда пользователи начинают понимать, как создавать новые формы и представления в SharePoint... CRIKY!! Поговорите о ползучести области!
Изменение схемы во время выполнения редко является хорошей идеей. Вы хотите рассмотреть модель EAV (Entity-Attribute-Value).
В Википедии некоторая очень хорошая информация о плюсах и минусах, а также о деталях реализации. EAV следует избегать, когда это возможно, но для ситуаций, подобных вашим, с неизвестным количеством столбцов для каждой формы, EAV рассматривает.
Сохраняйте нормализацию данных. Система будет оставаться быстрой, если у вас есть правильная индексация.
Если вы действительно хотите быстро перейти, переключите схему в одну из баз данных ключевых значений, таких как bigDB/couchDB и т.д. Это полностью денормализировано и очень быстро.
То, как я бы справился с этим, - использовать нормализованную расширяемую таблицу "Свойство", например, ниже:
Table: FormProperty
id: pk
form_id: fk(Form)
key: varchar(128)
value: varchar(2048)
Вышеприведенное является лишь примером, но во многих случаях я использовал этот шаблон, и он имеет тенденцию работать довольно хорошо. Единственное реальное "получение" - это то, что вам нужно сериализовать значение как строку /varchar, а затем десериализовать его на все, что должно быть, поэтому на клиенте есть небольшая дополнительная ответственность.
Нормализованный == быстрый поиск, упрощает ведение индексов, более медленные транзакции вставки (на несколько строк)
Денормализованные == быстрые вставки, обычно это используется, когда имеется много вложений (хранилища данных, которые собирают и записывают хронологические данные)