Почему все так ненавидят EAV?

hstore для постгреса не всегда ж доступен

Зато XML - штатный datatype

Почему все так ненавидят EAV?

Если это тот, который через table entity_properties (id serial not null, entity_id integer not null, property_id integer not null, property_value text) - то, и правда, это эльфийская БД получится.

1) Контроль типов значений этих самых attributes ты уже пролюбил (и теперь делаешь этот контроль application side) 2) А бывает еще бинарный атрибут у entity - еще одну табличку, или сразу property_value делаем BLOB, после чего доставляем себе массу удовольствия, разгребая тонны дескрипторов опять-таки на стороне приложения (и да, я знаю про сериализацию BLOB в тот же b64)?

Кстати, чем тебя LDAP не устраивает?

Меня в LDAP не устраивает то, что на его базе не так просто замутить программу для строительной кухни, типа смет, счетов, отчетов о проделанной работе, тендеров и прочего г. Вот реляционка — справляется. Но там есть такая неприятная вещь, как документы, а у них есть особые чудные свойства, а еще такие есть в заказах.

И мне кажется, что если у тебя несколько заказчиков в разных странах, то для вот этих кастомных свойств EAV — то, что доктор прописал. Кроме того, можно воткнуть костыль в виде property_type ENUM('string', 'integer', 'money', 'timestamp'), value_string TEXT, value_integer BIGINT, value_money DECIMAL(20,4), value_timestamp TIMESTAMP WITH TIME ZONE.

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

Если это тот, который через table entity_properties (id serial not null, entity_id integer not null, property_id integer not null, property_value text) - то, и правда, это эльфийская БД получится.

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

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

P.S. К сожалению сам такой.
P.P.S. К счастью разработкой БД заниматься приходится не чаще 1-го раза в 2-3 года.

Э, нет, родной, эльфийский софт — это такой, в котором даже суперъюзер не может ничего задним числом поменять.

Или отметил ты окончание торгов, и капут, даже имени заказчика сменить не можешь. А он, зараза такая, на третий месяц слился в экстазе с другой конторой, да название с адресом поменял.

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

В неэльфиском можно не «сменить наименование, ИНН, ОКПО, ОКУД и т.д.», а «добавить новые реквизиты [ ] сделать реквизиты активными с данного момента [__.__.____] сделать реквизиты активными с указанной даты».

воткнуть костыль в виде property_type ENUM('string', 'integer', 'money', 'timestamp'), value_string TEXT, value_integer BIGINT, value_money DECIMAL(20,4), value_timestamp TIMESTAMP WITH TIME ZONE.

Именно поэтому, кстати. property_type по идее должен сидеть в таблице, которая описывает вообще этот property. Но, как только мы разносим сущности по разным таблицам, начинается беготня с тем, что одни property вот этому entity MUST, другие MAY, третьи MUST NOT (извини, что почти в терминах LDAP). И так для каждой сущности. Со временем DB-schema становится просто overengineered, равно как и запросы на выборку данных из такой схемы. Это, мне кажется, главная опасность EAV.

Во-первых, неприятно делать запросы с фильтрацией по полям. Там нужен JOIN, я натыкался как-то на лимит джойнов (в мускуле 61). Да и сами джойны не такие быстрые, как хочется.

Во-вторых, довольно много возни в коде.

Тот же hstore ни разу не заменяет EAV, кстати, так как хранит данные только в виде строк. Можно, конечно, делать functional index-ы, но всё же.

там где нужна документ-ориентированность — бери документ-ориентированную бд /thread

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

Скорее у орков :)

Скорее у орков :)

Как вы грубо про 1С... :-)

а что такое EAV? Кто все эти люди в треде, которые его обсуждают?

а что такое EAV?

Для забаненных в гугле:

http://en.wikipedia.org/wiki/Entity–attribute–value_model