Возьмем за пример avito и его объявления с разными свойствами для категории. Подскажите, пожалуйста, жизнеспособна ли структура EAV на такой объем данных в реляционной бд?

Или же лучше использовать иные подходы:

1. На каждую категорию товаров - своя таблица.

2. Использовать не реляционные бд, например, MongoDB.

babonacapscom,

вредна ли водка?
вреден ли змеиный яд?
что лучше самолёт или вертолет?

У меня опыт небольшой и пришел спросить совета. Возможно люди обкатали схемы на рабочих проектах и знают их подводные камни. В рамках маленького сервиса, понятно, что любой подход жизнеспособен.

Dimitry SibiryakovcapscomУ меня опыт небольшой и пришел спросить совета.
Жизнеспособность EAV в конкретном проекте зависит не от объёма данных, а от требований
проекта и радиуса кривизны рук программиста. И таки да, в неопытных руках оно сдохнет
практически наверняка.


А требований исходить, чтобы было четкое понимает, что тут нужен EAV, а тут отдельные таблицы?

Dimitry SibiryakovcapscomА из каких требований исходить, чтобы было четкое понимает, что тут нужен EAV, а тут
отдельные таблицы?
Да.


Что да?)) Меня интересует на основании каких критериев можно определиться нужен ли EAV или же иные подходы?

Dimitry SibiryakovcapscomМеня интересует на основании каких критериев можно определиться нужен ли EAV
или же иные подходы?
Опыт разработчика приложения - главный критерий. Остальное вторично.


У Вас наверняка большой опыт, поделитесь, пожалуйста. Если бы Вам пришлось проектировать Авито, в какую структуру Вы бы укладывали данные?

SERG1257, поддерживаю




Задача:
Каждая категория имеет свои свойства разных типов (text, checkbox, int). Необходимо дать пользователю возможность размещать объявления в различных категориях, а так же фильтровать объявления по заданным свойствам.

Рассмотрим подход EAV.

Его основным плюсом будет гибкость добавления новых свойств для категории.

Недостатки:
1. Есть громоздкость в сборе данных(или их группе),
2. Некоторые свойства могут быть связанными (бренд-модель) и их придется выносить в отдельные таблицы, что еще больше увеличит громоздкость запросом при сборке данных.
3. При добавлении нового свойства с дефолтным значением, придется бежать по всей группе объявлений и его проставлять.
4. Значения всех свойств varchar (возможные проблемы с индексацией и фильтрацией по атрибуту?)

Часть проблем, можно устранить кешированием (уровень приложения не рассматриваем).

Рассмотрим подход с отдельными таблицами для каждой категории товаров.

Его плюсами будут:
1. Довольно прозрачные запросы при сборке данных.
2. Свойства товара будут иметь корректные типы, соответственно проще фильтровать.

Минусы:
1. Полное отсутствие гибкости при добавлении нового атрибута.
2. При большем количестве категорий, например 100, имеем 100 таблиц в бд. (мне сложно определиться, является ли этот критерий недостатком)


Покритикуйте, пожалуйста.

ChAПоследний раз, когда был на avito, не заметил там необходимости в EAV. Объявления в форме сводбодного описания. Достаточно иерархического классификатора, таблицы объявлений с поддержкой полнотекстового поиска и парой-тройкой дополнительных таблиц для фото и пользователей и ещё какой-нибудь мелочи.


Не очень понял, что имеется ввиду под иерархическим классификатором. Напишите, пожалуйста, подробнее (если не сложно с примером)

ChA,

Допустим вся иерархия категорий будет представлена в таблице как NestedSets:

- Транспорт/Автомобили/Ford/Focus
- Работа/Вакансии/IT, интернет, телеком

А как вы предлагается хранить различные свойства ? На каждый тип (Транспорт, Работа) - отдельные таблицы?

ChAcapscomДопустим вся иерархия категорий будет представлена в таблице как NestedSets:

- Транспорт/Автомобили/Ford/Focus
- Работа/Вакансии/IT, интернет, телекомIMHO, NestedSet не лучший вариант хранения иерархии, но хозяин - барин. Если иерархия достаточно стабильная, то можно и её использовать, хотя запросы, на мой взгляд, бывают сложноваты.
capscomА как вы предлагается хранить различные свойства ? На каждый тип (Транспорт, Работа) - отдельные таблицы?Если обратите внимание, то у них только в нескольких категориях есть уточняющие характеристики, так что отдельных таблиц более чем достаточно. Вы же не пытаетесь сделать универсальную БД на всё во Вселенной ?

Спасибо большое ) Теперь ясно ) Нет, вовсе не универсальную. Просто интересно, какие из вариантов наиболее жизнеспособны в действующих проектах.

MasterZiv, а есть пример "правильной готовки" ?