Предыдущая моя тема выдохлась.
http://sql.ru/forum/actualthread.aspx?tid=653190

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

EAV против native create table

Немного расшифровки
Для возможности создавать динамически изменяемые таблиц что лучше
Использовать частично или полностью EAV (ну или вообще какую то другую виртуализацию типа мусорных таблиц) или использовать простой create table (прямой или косвенный через какое то метаописание типа orm или xml)

Данная возможность нужна скорее не для конечного пользователя а например для модератора или администратора системы то есть человека в какой то степени квалифицированного.

Прошу всех высказывать аргументы только за и против. одного из подходов.
Если бы возможно было бы создать голосования я его создал бы здесь. Дополнительно. Ну можете написать за какой подход вы.

guest_20040621,

честность ценю. И какой же есть третий вариант ?

Foxluck,

Ну Волга же лучше Запорожца :)

Ладно освежу тему новой информацией.
Вот я юзаю такой популярный фреймворк как django

Если кто не в курсе у Django есть ORM.
как он работает.

Мы создаем модели (классы). И далее работаем с экземплярами этих классов то есть объектами. Причем поддерживаться и наследование. и много чего еще.

Как эти объекты представлены на физическом уровне.
это просто таблицы.

то есть выполняя
команду
manage.py syncdb

Происходит
много
create table если конечно сущности еще не были созданы.

И вот например есть объект
User - этот класс нужен не изменным так как он используеться в модуле авторизации

Но мне нужен User со своими дополнительными полями.

Вот он случай когда пользователю нужны свои дополнительные поля.
Там есть два варианта как это решаеться это profile (не буду о нем сейчас) и более интересный который я использую наследование от User
То есть я делаю

class CustomUser(User):
....

физически
при manage.py syncdb
создается еще одна таблица.

Как я это вижу тут именно избран подход. create table и он неплохо работает.
Но кто то может сказать что это не тоже самое. Может быть буду услышать рад аргументацию.

guest_20040621,

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

Ну вот есть если какое это метаописание но на физическом уровне это либо create table либо EAV.

Гибридное решение с xml где в одно дополнительное поле сохраняются все дополнительные поля.
это компромиссная ситуация.

guest_20040621> к сожалению все эти подходы сводяться по сути к двум

К двум десяткам, Вы хотели сказать?



Перечислите на вскидку сколько все вспомните ?

guest_20040621,

Пришли к метаописаниям.. :) Да наверное в случае метаописаний виртуализация оправдана. Ведь в этом случае субд выступает тупо в роли физического носителя. чуть более комфортного чем файлы. Кое что доходит стало

Хоть кто то выступил на другой стороне ASCRUS

Про EAV мыши плакали и кололись но все равно жрали кактус :)
модель Тенцера я так понял это просто другое название

Для простейшего функционала может сойдет. Но в дальнешем мы создадим свою СУБД . А свою С
УБД сопаставимую с современными наверное сложно сделать.

Допустим мы отказались от хранения метанинформации EAV в обычной базе данных.

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


Ну вроде сейчас получается стандартом де факто для таких случаев является EAV. Какие то экзотические возможности есть (вроде документоориентированных субд например CoucheDB). но их наверное никто не сможет порекомендовать или сможет?

У нас есть проблемы с тем что у нас рел. субд оперирует четко типизированными объектами.

ddl вроде и изменяет тип сущностей и создает новые

По поводу того что страшно давать пользователю create table
но мы отдаем не весь ddl а только определенные частные случаи.
Да и не всякому пользователю мы дадим такие права только доверенным лицам.
Да может мне и самому так удобнее будет расширять систему. Можно сказать мой девелоперский иструмент дополнительный.


По поводу проблем многотранзакционности интересное замечание. Ну могут быть какие то проблемы но тоже решаемые скорее всего.