Вот и я примерно о том же. В этом топике очевидно, что у ТС нет достаточного понимания  ER модели, и это, пожалуй единственная проблема которая перед ним стоит. Ваш совет реализовать EAV средствами РСУБД носит явно деструктивный характер, т.к. ТС не может оценить недостатков этой модели, в то время как достоинства для нуба кажутся очевидными. До тех пор, пока в ответ на вопрос чем insert предпочтительнее alter table не прозвучит разумного  ответа, мол DDL не журналируется, говорить о преимуществах EAV не имеет смысла, тк. это, пожалуй, единственное преимущество этой модели. Ничего в этом топике не говорит о том, что действительно следует воспользоваться этим преимуществом.

Печаль, вы меня утомляете. 

Я не собираюсь вам доказывать, что вы глупее меня. Оставлю это вам, поскольку верю - вы справитесь.

•  1. Я отвечал не топикстартеру а Gold Dragon. На его хранение нескольких атрибутов в одном поле.
•  2. Пойдите почитайте хотя бы wiki о том, где удобно EAV. Да, я об этом тоже не упомянул в контексте топика поскольку считал, что люди неглупые - сами прочтут. Вижу - ошибался.
  В частности - разреженные массивы данных вы можете хранить в чем угодно, но когда у вас на таблицу из сотен полей будет использоваться от силы десяток-другой, то ваше упрямство поставит вас в неудобную позу.
•  3. DDL отлично журналируется вместе с другими запросами, буде мы используем не голую БД, а конкретное приложение.
•  4. Вы упускаете тот момент, что в случае EAV вопрос связей между сущностями ложиться не на БД, а на приложение. И это не недостаток, это особенность модели.
  И именно ваше незнание привело вас к тому что вы получили ручкой граблей по лбу и теперь регулярно в каждом топике плюетесь в сторону EAV.

За сим я откланиваюсь.

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


Это сообщение отредактировал(а) Zloxa - 3.9.2009, 14:41

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

а теперь по теме.. я всего-лишь предложил вариант решения.. задачи то ведь бывают разные 
Например, у меня в проекте примерно около 100 модулей, которые имеют собственные характеристики.. Каждый объект может иметь любое сочетание этих модулей. Это поле только содержит данные в формате Ключ->Значение... Никакой поиск по этим полям не ведётся, да и он не нужен... Есть другое индексированное поле для таких целей  Так что выгоднее найти запись по индексу и достать данные из поля чем построить абсолютно никому не нужные 100 таблиц с данными и ещё таблицу согласования 

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

Хотя мой опыт тоже может ошибаться.

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

P.S. хотя тот же MSSQL, Oracle, Firebird, да и MySQL последних версий дают возможность весь интерфейс работы с сущностями заложить в БД в виде хранимых процедур, триггеров и view.
Тогда для конечного приложения это будет мало отличаться от работы с обычной таблицей.