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

Пока классифицировал на такие варианты:

1. "Двухуровневое решение" - к таблице сущности (товар, посетитель) добавляет простую таблицу "ид_сущности, имя_параметра - строка_значение"

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

Недостатки:
а) значение - только строка (преобразования типов)
б) недостаточная нормализация (повторяемость имен параметров)

Достоинство вижу только одно - скорость выборок.

2. "Трехуровневое решение" - значения хранятся в отдельных таблицах значений (по типам данных например), имена - суть значения предопределенного типа (например char(64) ) в отдельной таблице. В этом случае, дополнительная таблица параметров становится примерно такой: (object_id, paramName_id, paramType_id, paramValue_id), где paramType_id -- какой-либо способ идентификации таблицы конкретной таблицы значений.

3. Вариант 2 с динамическим DDL для построения упрощенных с точки зрения выборки представлениями.

4. Вариант 2 с дополнительным полем parent_id -- позволяет организовывать "вложенность параметров" и/или их контекстную зависимость. Как равиант "ускорения" работы с параметрами - вижу применение плагинов прямого доступа к индексам (handlerSocket к примеру)

... приглашаю гуру добавлять/критиковать подходы к реализации EAV силами Мускуля.

miksoft,
а зря. Планировал показать как можно использовать handlerSocket в реализации..

miksoft,
блин, я только выкачал это всё, сижу собираю... ещё ни разу ни компилял Мускуль с плагинами... ;)

Максим Н, собственно именно этим и планировал заняться (рабочее название mumpsDb), но похоже что "без надобности".

sp_мод,

ну если сумасшедший администратор даст права рядовому юзеру - может и он :)
как правило этим должны заниматься аналитики

ИМХО, но именно этот Ваш ответ "не в тему" и привел ко флуду ниже. Поскольку автор - то хочется попросить модеров снести тол что было ниже.

Конкретно Вам:

1. Вопрос был задан по-существу. И он - как ни странно, основной. "Хто будет рулить?"
Варианты ответа:
а) программисты (DBA + прикладник) -- в этом случае "проблем ваще нет" - добавляем, переделываем структуру данных, приложения, наворачиваем фильтры, валидаторы, интерфейсы, связи со старыми данными и т.д. От этого "поклона" дорогим и любимым говнокодерам (как тем так и другим) и хочется уйти совсем. Причем всем и давно. ;)

б) пользователь -- и? куды Вы от EAV денетесь? :) Недостатки хорошо изучены, и Вы правы: тормоза системы на больших данных/нагрузках. И даже mumps не спасение. Вот как раз тут, могут быть гибридные решения: что-то в основных структурах (фиксированно), что-то туда динамически лезет (что надо быстро И позволяет обходится имеющимися ТИПОВЫМИ интерфейсами), что-то чистым EAV.

в) ал-ля ЦМС - метаструктуры, метапрограммирование... всё это хорошо, когда есть готовые (читай типовые) интерфейсы использования... а когда их нет?
Как к примеру, пользователь, добавив к сущности пользователя (под)колонку: "Образование"->"ВУЗ"->"специальность"(ид строки справочника "Специальности ВУЗОВ") может привязать обработку валидатором с проверкой наличия данной специальности в данном ВУЗе в заданный период обучения ... БЕЗ шаманства и п."а"? только силами ЦМС? Или сгенерит событие-уведомление всем, пользователям, которые имеют тот же самый ВУЗ уведомление о добавлении "однокурсника" (ишо период обучения совпадать должон)? Или ... Всё что он сможет сделать ... должно быть заранее реализовано в ЦМС или создаем ещё один "метаязык" и обучаем новых "метаговнокодеров". Круг замкнулся.

И ведь это не единственные проблемы ... их тыщи! ;)

Так вот, несмотря на свой недостаток (он практически единственный) - EAV позволяет динамически наращивать структуры данных ручками самих пользователей... впрочем и обработки тоже.