Здравствуйте. 
Решил сделать сайт на подобие 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 параметрами ... к чему клоню - разделение какое не выгодное.

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