Ога, а потом умри на отборе. Ибо, как всегда внезапно окажется, что к предикатам отбора надо будет применять не только OR, но еще и AND, а предикаты, как назло окажутся один неселективнее другого.

Но, через это таки надо пройти   


http://lmgtfy.com/?q=EAV&l=1


Я полагаю, что  РБД не лучшая платформа для подобных решений. Вполне возможно что я заблуждаюсь ввиду полного отсутствия познаний в нереляционных БД и слишком хорошо о них думаю. Мои размышления базируются на том, что организации подобного рода данных не нужна реляция, не нужен ACID и не нужны не малые издержки на всю эту хреноту. Возможно какое то гибридное решение - РБД на этапе ввода, модерации и классификации, потом постановка на нереляционную витрину, оптимизированную для отбора.

В общем прочитал я про EAV, любопытный конечно подход, но что-то эту модель критикуют часто.
Вот интересная статья http://zlob.in/2013/01/struktura-tablic-dl...ernet-magazina/
Еще вот это вот интересно http://fenix.kiev.ua/eav_vs_row_modeling_t...i_na_postgresql

Какой отсюдова делаю вывод:
1. EAV не использовать, а использовать ROW MODELING (все таки части будут забиваться NULL-ами)
2. Создать таблицу главных сущностей, вписать туда то что есть общее во всех объявлениях
3. Для каждой категории сделать свою таблицу, тогда получится таблиц 53.
4. Далее программным путем распределять объявления по этим таблицам, а если делать общий поиск, то придется перебирать искомую фразу во всех этих таблицах ... а что делать!?

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

Что скажете?

Цэны нет только у денег. Да и то, FOREX что-то такое предоставляет.

Заголовок -- тожэ обязательная часть вежливого сообщения.
Список фоток можно ещё в единую таблицу (один-ко-многим или многие-ко-многим).



Вполне жызненно. В отличие от идеи хранить DESC/user в каждой таблицэ отдельно.
Можно ещё пообъединять в иерархию таблиц: объединить, например, новые и БУ автомобили, выкинуть только отличия в разные таблицы.

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

ну ну.
поведай плиз какие "индэксы хоршы" для отбора вроде

если sex, country и birth_date хранятся в вертикалке.

Это сообщение отредактировал(а) Zloxa - 15.8.2014, 13:35

Чаще всего -- отдельный индэкс на (type=const('birth_date'), value) выдаёт очень близкий к нужному результат. В смысле -- что скорость выборки не слишком отличается от оптимальной.

В остальных можно выкручиваться: например, сделать EAV-таблицу через view на реальное EAV и комплект ускорятелей с индэксами.

PS Кстати, топикстартеру: про country='' -- очень правильное замечание, регион такжэ должэн являться свойством основной таблички.

Создал таблицы, упорядочил как мог, вот что в итоге получилось если ориентироваться на сайт Avito.ru:

1. Создал основную конечно же таблицу для объявлений
http://ipicture.kz/images/2014/08/jftuaazqmq02ne2a08ym.jpg

•  category - определяет к какой категории принадлежит объявление
•  title - заголовок, и да, он нужен постоянно, просто иногда, в некоторых разделах, он гинерируется программой
•  description - пользовательское описание объявления, оно есть в каждом объявлении
•  tel - телефон в любом случае
•  email - мэйл в любом случае
•  city_id - город, в моем случае городов не много
•  ip - на всякий случай, а то ведь объявления и без регистрации будет приниматься
•  private - отвечает за частное объявление или компании
•  first_name - тоже нужен в любом случае, чтоб знать к кому обращаться
•  price - цена, но в категории знакомств людей там будет стоять NULL, в др. случаях цифра включая 0 (ноль)
•  user_id - айди юзера, того кто уже является разегистрированным
•  photos - тут будут ссылки на фото хранится, через запятую или объектом в виде строки
•  hide - открыто/закрыто объявление
•  allow_mails - разрешает получать письма пользователю от портала
•  time_create - время создания
•  time_edit - время редактирования

2. Далее создал одну таблицу в каторых помещаются те объявления, каторые состоят из одной доп. опции или двух доп. опций. В этой таблице хранятся id-шки от других таблиц. Если к примеру выбирая категорию из меню объявлений и данная категория имеет только одну подкатегорию, то второе значение в этой таблице, конечно же остается NULL-ом, а если у подкатегории имеется, у какого либо элемента, еще свои одна опция, то она записывается во второе поле таблицы и т.д.
http://ipicture.kz/images/2014/08/lqwfo1tf82jkkurjqz5a.jpg

•  ad_id - айди объявления
•  kind - первая доп. опция
•  type - вторая доп. опция

Это были основные таблицы объявлений.
3. Далее идут таблицы каторые сильно отличаются своими параметрами. Из 53 планируемых таблиц 8 из них опустились, потому что по параметрам им хватало таблицы из первого пункта ... 30 таблиц улетело в таблицу под пукнтом 2 ... а другие оставшиеся они и являются специфическими, каторые нужно создать отдельно.

В итоге получается 14 таблиц, львиную долю каторых составляют таблицы связанные с недвижемостью.
http://ipicture.kz/images/2014/08/930k33yjbnvzrgg7132d.jpg

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

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

Такие вот дела ...

Добавлено через 8 минут и 13 секунд
Не сомниваюсь что придется еще не раз там исправлять детали. Это пока черновой вариант. Спасибо.

Это сообщение отредактировал(а) numerovan - 18.8.2014, 02:26

Это называется "справочники".

Да, выглядит достаточно вменяемо.