Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.139.233.43] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
1) Таблица объектов (системная инфа, видимость, автор, дата постинга, просмотры)
2) Таблица параметров 3) Таблица значений 4) Таблица-связка 2-3 Добавлено Спящий, что считать основными параметрами это другое, я примеры того что считаю основными написал - это внутренние поля объекта, цену туда можно тоже включить. Добавлено 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 ) 1) Решается проблема с количеством условий, если уж запрос привысил max_allow_packet, который увеличивается до достаточно больших размеров (по-умолчанию 8мб). Решается с помощью занесения условий во временную таблицу. Изврат, но и проблемы такой не будет, но для чистоты это хорошее свойство, уперется можно разве только в размер временнной таблицы. 2) Более полезное преимущество это видимость количества совпавших условий, следовательно можно создавать нечеткий поиск "у нас не нашлось подходящей машины но есть очень похожая". Так сказать получается автоматически релевантный поиск одним запросом. Добавлено Кстати хранение параметров в одной строке тоже когда-нибудь упрется в ограничение сложности запроса, так что это вариант еще и лучше. |
Сообщ.
#17
,
|
|
|
Цитата Pr0[)!9Y @ Не понимаю, зачем заводить отдельно таблицу-связку. Принципиально хочется иметь таблицу из одних идентификаторов?1) Таблица объектов (системная инфа, видимость, автор, дата постинга, просмотры) 2) Таблица параметров 3) Таблица значений 4) Таблица-связка 2-3 Цитата Pr0[)!9Y @ ИМХО, конечно, но основными имеет смысл делать только поля, входящие в первичный ключ. Хотя конечно, можно таким образом избавиться от дополнительных запросов/джойнов, но при грамотно расставленых ключах это будет давать прирост производительности только на совсем огромных базах. Спящий, что считать основными параметрами это другое, я примеры того что считаю основными написал - это внутренние поля объекта, цену туда можно тоже включить. |
Сообщ.
#18
,
|
|
|
Цитата Спящий @ Принципиально хочется иметь таблицу из одних идентификаторов? Цитата (Pr0[)!9Y @ 7.12.09, 16:31) Цитата Pr0[)!9Y @ Таблица возможных значений\подтановок. Так правильнее. 3) Таблица значений |
Сообщ.
#19
,
|
|
|
Цитата Pr0[)!9Y @ Это понятно. Таблица связей зачем отдельно от таблицы объектов? Таблица возможных значений\подтановок. Так правильнее. |
Сообщ.
#20
,
|
|
|
Потому что у одного объекта много свойств, а свойства ограничены установленным списком.
|
Сообщ.
#21
,
|
|
|
Цитата Pr0[)!9Y @ тут я придумал вариант который наверно все же будет быстрее, чем предполагаемый мной ранее джоин на каждое условие. Но проверить я не могу к величайшему сожалению. Вполне стандартный подход. Правда, лучше делать промежуточную выборку во временную таблицу - это упростит выдачу чётких и нечётких совпадений и позволит повторно использовать те же данные в рамках сеанса без повторного выполнения выборки. Добавлено Цитата Спящий @ Не понимаю, зачем заводить отдельно таблицу-связку. Принципиально хочется иметь таблицу из одних идентификаторов? Скорость, скорость. Работать только с индексами, без значений - намного быстрее. |
Сообщ.
#22
,
|
|
|
Цитата Akina @ Интересно получается. Т.е. если в таблице галимые индексы, то она работает быстрее, чем если таже таблица, но хотя-бы с одним неиндексированым полем? И намного? Скорость, скорость. Работать только с индексами, без значений - намного быстрее. |
Сообщ.
#23
,
|
|
|
Альтернативы нет =) С голыми значениями не получится никак сделать.
У строк должен быть идентификатор разный, если это разные вещи, а что значение совпадает это случайности. |
Сообщ.
#24
,
|
|
|
Цитата Спящий @ И намного? А насколько скан таблицы медленнее поиска по индексу. Сортированному, кстати. |
Сообщ.
#25
,
|
|
|
Дак никто-ж не собирается искать не_по_индексу. Или это сама СУБД будет зачем-то делать?
|