Критика мой дизайн базы данных MySQL для неограниченных ДИНАМИЧЕСКИХ полей

Question

В поисках масштабируемой, гибкой и быстрой базы данных для веб-сайта в стиле «Создайте свою собственную форму» - например, Wufoo .

Правила:

1. У пользователя есть только 1 форма, которую он может построить
2. Пользователь может создавать свои собственные поля или выбирать из «стандартных» полей
3. Форма пользователя 1 имеет столько полей, сколько хочет пользователь
4. Значения могут быть родственными значениями другого значения E.g. Значение фотографии может иметь имя, местоположение, ширину и высоту в качестве значений одноуровневого элемента

Специальные правила:

1. Пользователь может отправить свою форму максимум 5 раз в день
2. Дата значения важна
3. Очень важна гибкость отчета о значениях (для одного пользователя, для всех пользователей, 1 поле, много полей) - визуализация данных (большинство из них будут основаны на хронологии, например, все фотографии за июль 2009 г. для всех пользователей).

Таблица "пользователи"

UID

Таблица "field_user" - назначить поле для формы пользователя

шлагты

UID

weight - int - используется для заказа полей в форме пользователя

Таблица "Поля"

шлагты

creator_uid - int - поле 'создатель'

этикетка - varchar - например, E-mail

value_type - varchar - используется для определения того, какое поле в таблице «значений» будет заполнено (например, если «int», то значения этого поля будут передавать данные в поле values.type_int - и все остальные поля .type_x будут быть NULL).

field_type - varchar - например, «электронная почта» - используется для особых условий, например, правила проверки

Таблица "значений"

VID

parent_vid

шлагты

UID

дата - дата

date_group - int - значение 1-5 (пользователь может отправлять не более 5 форм в день)

type_varchar - varchar

type_text - text

type_int - int

type_float - float

type_bool - bool

type_date - date

type_timestamp - отметка времени

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

Answer 1

Вчера в OSCON Джош Беркус дал хорошее руководство по проектированию БД, и он потратил немалую часть этого безжалостно, разбираясь в таких таблицах " EAV "; вскоре вы сможете найти его слайды на сайте OSCON и, в конечном итоге, аудиозапись всего его учебника в Интернете (последнее, вероятно, займет некоторое время).

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

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

Answer 2

Вы действительно должны смотреть на базы данных без схемы, такие как CouchDB , проблемы, подобные этой, как раз и решают эти типы БД.

Answer 3

Я согласен с Джоном Оуэном.

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

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

Answer 4

знаете, создание таблицы, изменение, добавление столбца и т. Д. - это операции, которые вы можете выполнять во время выполнения во многих современных реализациях rdbms. Зачем быть EAVil? Особенно если вы используете динамический sql.

Это не для слабонервных. Я вспоминаю реализацию в Boeing, которая привела к созданию 70000 таблиц в базе данных.

Очевидно, что при создании динамических таблиц есть подводные камни, но они существуют и для таблиц EAV. Такие вещи, как два атрибута для одного и того же ключа, выражающие один и тот же факт. Или переходные зависимости и другие ошибки нормализации. Так почему бы хотя бы не использовать возможности СУБД от вашего имени?