Всем добрый вечер,

по задаче необходимо реализовать более 10 таблиц с разным количеством и типами полей. Я подумал и сделал в виде EAV следующим образом:




1. Кто нибудь сталкивался с такими задачами? Не хочется плодить 10 новых таблиц, тем более что поля таблиц и их количество могут изменяться. Какие подводные камни есть в EAV?
2. Как можно такую таблицу проиндексировать?
3. Лучше хранить все в стрингах или в entity_attr_value стоит добавить вместо str_value три поля например str_value,number_value и date_value?

если можно поделить плз ссылками.
Спасибо.

адма и еавcobalt_frog,

Если жизнь без eav не мила, бери nosql.

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

+ хотелось бы узнать, кто из форумчан использовал данный подход при решении задач, с какими трудностями сталкивался и как их решал)

maytoncobalt_frog2. Как можно такую таблицу проиндексировать?

На этот вопрос невозможно ответить. Ты должен подойти к бизнесу и спросить. Какие будут объемы? Какие
поисковые операции будут? Какие SLA стоят? Сколько милисекунд согласны ждать и т.п.
Потом проанализировать какие их этих операций будут затрагивать какие поля. Возможно
будет два сета полей. Один - денормализованный (обычные плоские таблицы). Проиндексированный.
Второй сет - будет лежать в EAV как дополнение. Туда пойдут всякие descriptions, comments, и редко
используемые атрибуты типа "диаметр_хомута_топливного_шланга" e.t.c. Потом построить макет
и прогнать на нем свои требования.

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

Объемы - десятки тысяч записей в месяц, ждать согласны хоть секунду, по этим данным будут обычные выгрузки в Excel, возможно изменение записи в последующем, поиск по какому либо полю (атрибуту).
Можно поподробнее по поводу:
mayton Возможно будет два сета полей. Один - денормализованный (обычные плоские таблицы). Проиндексированный.
Второй сет - будет лежать в EAV как дополнение. Туда пойдут всякие descriptions, comments, и редко
используемые атрибуты типа "диаметр_хомута_топливного_шланга" e.t.c. Потом построить макет
и прогнать на нем свои требования.
Если можно ссылку. Большое спасибо.

maytonСсылку не дам. Это просто из личного опыта. А ты должен привести примеры поисковых запросов.
На языке бизнес-постановки. "Найти все машины с 4 дверями и мощностью не менее..." и т.д.
И чем больше - тем лучше.

Найти все машины с 4 дверями

Найти количество всех машин красного цвета с количеством дверей <4

Найти дату самой первой модели машины

Найти стоимость всех машин с датой создания < 2000 года

Интересует как организовать два сета полей(денормализованынй и eav) для примера который я привел.
Спасибо.

to mayton
Хотелось ыб увидеть пример именно смешанной структуры (реляционной и eav).

Basil A. Sidorov... а потом появляются новые хотелки и "тщательно продуманная струкура" идёт в хлам.
хотелки будут, могут добавляться/удаляться некоторые из полей, если только eav использовать это решается просто созданием новой сущности и нового атрибутного состава для нее, если смешанная модель, то возникают проблемы.