Здравствуйте. 
Решил сделать сайт на подобие AVITO.ru. Покопавшись в фильтре сайта и посмотрев перечень услуг данного сайта понял что лучше посоветоваться тут с людьми, потому что там много разных вариантов выбора чего либо.

Посмотрите пожалуйста там весь перечень сортирования.
Как на ваш взгляд лучше организовать таблицы в базе данных?

Для того, чтобы разарботать схему БД, обычно собирается группа умных дядек (человек 5-10) и начинают долго и муторно обсуждать задачи, которые должна решать система. Потом рисуют много схем. Потом пишут спайк (черновик) проекта, который оценивает жизнеспособность придуманной системы. Попутно в схему вносятся изменения и улучшения. Также меняются задачи и их решения. После того, как спайк написан, все эти дядьки снова начинают обсуждать, что получилось, а что нет. Если всё устраивает, выбрасывают спайк и начинают писать новую систему с нуля, с учётом всех замечаний выяленных на последнем обсуждении.
Всё это, для проектов масштаба Avito, занимает примерно 1-3 месяца. Ты хочешь, чтобы тебе здесь сейчас на-гора выдали схему?   

Да, понимаю - не простая задача, поэтому сюда решил обратиться. Ведь от составления базы зависит и быстродействие и т.д.

Думаю нужно спросить более по точнее. Вопрос не закрыт, если что буду отписывать сюда идеи.

Самые базовые атрибуты (автора, цэну, дату, вероятно город) -- пишэшь в основную табличку, видимо, вместе с текстом объявления (вероятно, с вменяемыми словарями, т.е. явно в этой табличке должны быть ссылка на автора, а не ФИО).
Остальное (типы подвидов вещей и пр.) -- в виде key-value pairs со ссылками на эту таблицу.

Добавлено через 5 минут и 58 секунд
И да, я никогда не видел, чтобы 10 человек сидели и обсуждали конкретное SQL хранилище. Ни 3 месяца, ни 3 дня. На мозговой штурм такую гопу народа -- можно согнать, но это несколько часов (да и совершэнно непонятно, нафига оно для такой очевидной инжэнерной задачи). 

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

Тут есть два варианта: 
1. Один-два человека за два часа рисуют схему и сразу пишут проект. Тогда придётся корячить схему уже в продакшене, когда всё начнёт адово тормозить. В лучшем случае удастся всё  зарефакторить и перелить существующие данные в новую схему. В худшем -- придётся выкинуть проект и переписать всё с нуля. Второй вариант грозит лишением премии и иными неприятными вещами, так как заказчик будет вынужден оплачивать разработку второй раз.
2. Потратить месяц-два на продумывание всех аспектов и тюнинг всех запросов и получить дополнительную премию.

Добавлено через 2 минуты и 31 секунду

Возможно, что ты никогда не занимался хайлоадом...

Возможно, учитывая, что это вопрос определений.
А вот ты, похожэ, вообще никогда не делал схем SQL баз данных, и не работал плотно с приличными СУБД -- максимум -- или однострочные запросы или через данный свышэ орм к данной свышэ схеме.

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

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

Вот осн. критерии объявлений:

это как бы самые главные родители


 далее идут их потомки


К чем я это указал тут: сделать столько разновидностей объявлений сколько этих и потомок существует, допустим категория "Автомобили с пробегом" ... теперь тут нужно определится какие параметры будет содержать таблица, что нужно обязательно, а что нет. Что нам нужно будет обязательно в данной категории? По любому цена, текст описания, конкретная марка машины (модель не обязательна), пользователь кто это создал, дата создания, дата изменения ... остальные все приблуды как дополнительные опции, это касается и фотографий, хотя фото тоже можно сделать обязательным параметрам, как вы думаете?

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

Я так себе вижу эту ситуацию. Что вы думаете по этому поводу? Есть ли варианты упростить все это?

В фэйсбуке, говорят, этот справочник ужэ на 50 элементов. Так что всё ещё впереди.



Есть.

Сейчас я думаю что и в будущем инопланетяне мне не нужны будут ))) , хотя хз

Добавлено через 4 минуты и 51 секунду
по поводу упрощения:
допустим нужно будет создать таблицы описывающие названия стран, метро, марки атомобилей, пола человека и т.д. ... для удобства можно разделить их в разные таблицы, но можно и все эти значения поместить в одну таблиц и по id цеплять их, получается вроде каша, но зато используется одна таблица, что наверняка ускорит работу ....
Что думаете по этому поводу: разделять лучше или все в одну таблицу? Это не касается самих объявлений и таблицы пользователей сайта.

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

собираю базу, уже наклепал 150 таблиц, как закончу выложу сюда для общего обозрения, если что подскажете что нибудь, спасибо.

Хотелось бы показать вам следующее:

ad_auto_used_car(пареметры) - названия отдельной таблицы для объявлений, а "параметры" это названия столбцов  втаблице. Решил выразить это таким образом.

Что думаю по этому поводу: таблиц для объявлений конечно еще больше стало, но зато каждая таблица под конкретную тематику, с одной стороны теперь у объявлений нет определенного своего ID как на Авито, конечно есть свое в таблице куда она приписана. Можно конечно сделать одну таблицу для всех объявлений, но при этом там столбцов будет штук 30-40 думаю и потом придется постоянно вычислять какие столбцы принадлежат конкретной категории объявлений.

ID конечно можно сделать, как на Авито, к каждому объявлению и чтоб он не повторялся, но при этом придется генерировать некий строку типа "weriousdfjhxcv,bn42134234987" и запысывать в др. таблицу, каторой будет принадлежать свой ID в спец. выделеной таблице ... 

Как вообще думаете?

Или лучше одну таблицу сделать под все объявления, столбцов конечно будет многовато, но думаю ни чего страшного. Что скажете?

Это сообщение отредактировал(а) numerovan - 14.8.2014, 19:04

Судя по тому, что ты не слушаешь совсем мои советы -- мне совершэнно незачем их советовать.

Общее что у все есть, так это только параметр "Описание объявления", а в других случаях то цены нет, то заголовка нет и т.д.

Что в итоге получается, если использовать вашу методику:
1. основная таблица объявлений
2. доп. таблица объявлений (EAV, что это значит я не знаю, но не суть, главно там лежат параметры отличающиеся по отношению к другим объявлениям)

В осн. таблице сделать поля: id, user, desc, время создания
А в другой таблице остальные все 30 параметров ... может тогда во едино все запихнуть? и получится таблица с 34 параметрами ... к чему клоню - разделение какое не выгодное.

Может я не прав, поправьте пожалуйста... 

Ога, а потом умри на отборе. Ибо, как всегда внезапно окажется, что к предикатам отбора надо будет применять не только 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

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

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