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

Question

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

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

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

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

Спасибо

Answer 1

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

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

Answer 2

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

Относительно безопасности: плоский подход потребует от вас написания большого количества операторов create / drop, alter table и т. Д., Т. Е. Намного больше кода и намного больше точек сбоя.

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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