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

Цитата Спящий @ 07.12.09, 09:17

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

1) Таблица объектов (системная инфа, видимость, автор, дата постинга, просмотры)
2) Таблица параметров
3) Таблица значений
4) Таблица-связка 2-3

Добавлено 07.12.09, 13:32
Спящий, что считать основными параметрами это другое, я примеры того что считаю основными написал - это внутренние поля объекта, цену туда можно тоже включить.

Добавлено 07.12.09, 13:46
Akina, тут я придумал вариант который наверно все же будет быстрее, чем предполагаемый мной ранее джоин на каждое условие. Но проверить я не могу к величайшему сожалению. Можно без IN, суть именно в постановке условий.
Запрос вида

SELECT *
FROM `auto`
WHERE `id` IN (
 SELECT `autoId`
 FROM `values`
 WHERE
  (`paramId` = 10 AND `value` = 12) OR
  (`paramId` = 11 AND `value` = 'Седан') OR
  (`paramId` = 12 AND `value` = 'Желтый')
 GROUP BY `autoId`
 HAVING COUNT(`value`) = 3
)

3 - это количество параметров в условии. Используя такой запрос появляются плюсы.
1) Решается проблема с количеством условий, если уж запрос привысил max_allow_packet, который увеличивается до достаточно больших размеров (по-умолчанию 8мб). Решается с помощью занесения условий во временную таблицу. Изврат, но и проблемы такой не будет, но для чистоты это хорошее свойство, уперется можно разве только в размер временнной таблицы.
2) Более полезное преимущество это видимость количества совпавших условий, следовательно можно создавать нечеткий поиск "у нас не нашлось подходящей машины но есть очень похожая". Так сказать получается автоматически релевантный поиск одним запросом.

Добавлено 07.12.09, 13:48
Кстати хранение параметров в одной строке тоже когда-нибудь упрется в ограничение сложности запроса, так что это вариант еще и лучше.

Цитата Pr0[)!9Y @ 07.12.09, 13:31

1) Таблица объектов (системная инфа, видимость, автор, дата постинга, просмотры)
2) Таблица параметров
3) Таблица значений
4) Таблица-связка 2-3

Не понимаю, зачем заводить отдельно таблицу-связку. Принципиально хочется иметь таблицу из одних идентификаторов?

Цитата Pr0[)!9Y @ 07.12.09, 13:31

Спящий, что считать основными параметрами это другое, я примеры того что считаю основными написал - это внутренние поля объекта, цену туда можно тоже включить.

ИМХО, конечно, но основными имеет смысл делать только поля, входящие в первичный ключ. Хотя конечно, можно таким образом избавиться от дополнительных запросов/джойнов, но при грамотно расставленых ключах это будет давать прирост производительности только на совсем огромных базах.

Цитата Спящий @ 09.12.09, 07:28

Принципиально хочется иметь таблицу из одних идентификаторов?
Цитата (Pr0[)!9Y @ 7.12.09, 16:31)

Цитата Pr0[)!9Y @ 07.12.09, 13:31

3) Таблица значений

Таблица возможных значений\подтановок. Так правильнее.

Цитата Pr0[)!9Y @ 09.12.09, 10:51

Таблица возможных значений\подтановок. Так правильнее.

Это понятно. Таблица связей зачем отдельно от таблицы объектов?

Потому что у одного объекта много свойств, а свойства ограничены установленным списком.

Цитата Pr0[)!9Y @ 07.12.09, 13:31

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

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

Добавлено 10.12.09, 08:27

Цитата Спящий @ 09.12.09, 07:28

Не понимаю, зачем заводить отдельно таблицу-связку. Принципиально хочется иметь таблицу из одних идентификаторов?

Скорость, скорость. Работать только с индексами, без значений - намного быстрее.

Цитата Akina @ 10.12.09, 08:26

Скорость, скорость. Работать только с индексами, без значений - намного быстрее.

Интересно получается. Т.е. если в таблице галимые индексы, то она работает быстрее, чем если таже таблица, но хотя-бы с одним неиндексированым полем? И намного?

Альтернативы нет =) С голыми значениями не получится никак сделать.
У строк должен быть идентификатор разный, если это разные вещи, а что значение совпадает это случайности.

Цитата Спящий @ 11.12.09, 17:38

И намного?

А насколько скан таблицы медленнее поиска по индексу. Сортированному, кстати.

Дак никто-ж не собирается искать не_по_индексу. Или это сама СУБД будет зачем-то делать?