правильная структура БД "авто объявления"

ads
ad_id, description, user_id,....
1, Продаю - срочно, 22

ad_setting_types
ad_setting_type_id, value
1, цвет
2, кузов
3, кпп

ad_setting_type_options
option_id, ad_setting_type_id, value
1, 1, желтый
2, 1, красный
3, 1, зеленый
4, 2, хетчбек
5, 2, седан
6, 3, механика
7, 3, автомат
8, 3, вариатор

таким образом мы можем описать зеленый хетчбек с механикой как
ad_settings
ad_id, option_id
1, 3
1, 4
1, 6

Рабочая схема, но столкнулся с проблемой когда пользователь заполняет customное поле

типа пробег, цена, грузоподъемность. Как и куда сохранять данные?

Заполнить в ту же таблицу где храняться ID машин? В основную в спец стоблцы.
Да и твой вариант модифицировать до ad_id, option, option_type не долго.
option_type: rel\text\еще_что_то

Интереснее лично мне во всем этом, это проблема скорости выборок. Как ты с этим справляешься?
Записи с переменным количеством полей -- похожая тема, и такой же вопрос начиная с поста #8

Да ладно скорости... а представь себе отбор по нескольким критериям, но не всем, в совокупности, да с разным типом (=, <, >=, between, etc.)... это ж какой запрос получится!

Akina, на самом деле несмотря на то, что прошло почти 3 года с того моего обсуждения. Вопрос для меня остался интересным и нерешенным.
Просто я не вижу других вариантов. Что еще можно предложить для тех же авто (не говоря о том если необходимо хранить разные типы объектов)? Таблицу с сотней колонок?

Добавлено 04.12.09, 21:34

Цитата Akina @ 04.12.09, 21:26

а представь себе отбор по нескольким критериям

Ну да.. по джойну на каждый параметр. Только запрос строить какой угодно сложный автоматически можно, все упирается в скорость его исполнения.

а если такой вариант ?
http://img707.imageshack.us/img707/3250/87734385.jpg

Получается лишнее условие.
Другая марка, и то что у тебя 3784 лишние строки. Тебе надо их связать, только ради того чтобы знать что это поле не требует зависимостей. Не очень логично.

Добавлено 05.12.09, 19:02
Правильная структура на мой взляд такова.
Автомобили

autoID	Цена
35	30000

Параметры

parID	Название	Тип
11	Мощность	integer
22	Марка	relatio

Значения параметров

valID	parID	value
123	22	Daewoo

Связи

autoID	parID	value	rel
35	11	175(л.с.)
35	22		123

Добавлено 05.12.09, 19:03
Но выборки смертельные.

Цитата Pr0[)!9Y @ 05.12.09, 18:49

Получается лишнее условие.
Другая марка, и то что у тебя 3784 лишние строки. Тебе надо их связать, только ради того чтобы знать что это поле не требует зависимостей. Не очень логично.

Добавлено 05.12.09, 19:02
Правильная структура на мой взляд такова.
Автомобили

autoID	Цена
35	30000

Параметры

parID	Название	Тип
11	Мощность	integer
22	Марка	relatio

Значения параметров

valID	parID	value
123	22	Daewoo

Связи

autoID	parID	value	rel
35	11	175(л.с.)
35	22		123

Добавлено 05.12.09, 19:03
Но выборки смертельные.

Если расставить индексы, все ок.
Только, что тестировал, таблица settings во время проведения теста хранила в себе 2 500 000 строк.

А условия, а поиск? Не верится мне в скорость.

Pr0[)!9Y
Спасибо.

Цитата Pr0[)!9Y @ 05.12.09, 18:49

Правильная структура на мой взляд такова.

ой мама ... У вас у автомобилей свойства постоянно меняются, была марка а стала мощность?
В такие табицы надо вписывать, то что "дополнительно", а вот все туда абсолютно не нужно.

Я посоветовал вписать изменяемые свойства в основную таблицу.

Цитата Pr0[)!9Y @ 04.12.09, 20:59

Заполнить в ту же таблицу где храняться ID машин? В основную в спец стоблцы.

Человеку этот вариант не понравился, да и вообще плохо что поля будут в разных структурах храниться. Половина так, а половина так.

Цитата SPM @ 06.12.09, 09:51

У вас у автомобилей свойства постоянно меняются, была марка а стала мощность?

Причем тут изменение какое-либо?

Не знаю как для топикстартера, но во втором посте я ссылку привел на мою тему. Как тогда хранить если у меня разные типы объектов? Раз уж темы пересекаются.

Цитата Pr0[)!9Y @ 06.12.09, 13:41

Причем тут изменение какое-либо?

А тогда зачем все эти "пляски"? Не проще ли все основные правметры держать вместе с сущностью?
Топикстартер явно говорит о "авто объявления", а не о складе в гипермаркете.

Цитата SPM @ 06.12.09, 13:46

Не проще ли все основные правметры держать вместе с сущностью?

Проще, лучше и быстрее.

Чего-то я не понимаю, зачем вообще делить параметры на основные и дополнительные.
Стоит либо забить все параметры в соотв. столбцы, либо в отдельную таблицу.

Если в отдельную, то как-нить так:
auto:

auto_id	param_id	value
1	5	1000
1	1	Daewoo
1	3	100000.00

params:

param_id	name	metric
1	Наименование
5	Пробег	км.
3	Цена	тугриков

Чего ещё выёживаться?

Добавлено 07.12.09, 09:23
Если нужны всякие там диапазоны вхождений, варианты выбора и т.п., то тогда стоит добавить отдельную таблицу с вариантами выбора (`param_id`, `value_id`, `value_name`, `order`), а в основной хранить value_id. Есс-но в у параметра должно быть указание, что выбор осуществляется из отд. таблицы.
Если-же это будет обрабатываться каким-нить пыхом, то можно завернуть их как-нить в одну строку и добавить в столбец таблицы параметров.

В любом случае, это 2-3 таблицы, а не 4.

Цитата Pr0[)!9Y @ 04.12.09, 21:31

Только запрос строить какой угодно сложный автоматически можно, все упирается в скорость его исполнения.

Ограничение на сложность запроса (да и тривиально на его размер) всё-таки есть. Другое дело что до него долго брести - но когда-нить непременно упрёшься.