| |
|
|
| | В таблице есть N полей, которые потенциально могут участвовать в выборке (попадут в WHERE). Комбинация этих полей может быть любой (в зависимости от того что выбрал пользователь для фильтрации результатов). Как выбирать индекс для такой ситуации или какие другие пути решения существуют? | |
| |
|
|
| |
|
|
| |
для: Igorek
(23.11.2012 в 13:50)
| | | Если речь идет о неопределенном количестве выбранных атрибутов (свойств) товара, или о чем-то похожем, то рассмотрите такой вариант организации хранения данных.
Он довольно заморочен в реализации, но универсален и нормализован при любом количестве аттрибутов.
И вот тут еще речь о том же самом, но под другим углом. | |
| |
|
|
| |
|
|
| |
для: Sfinks
(23.11.2012 в 15:16)
| | | я не про организацию хранения. здесь все просто - одна таблица, описывающая одну сущность с большим кол-вом параметров, но их фиксированное число N.
Наиболее частой задачей, выполняемой применительно к этой таблице, будет выборка по этим параметрам. Соответственно, хотелось бы избежать фулл скана таблицы, но т.к. комбинация этих параметров может быть любой, то я не представляю какой или какие надо создать для поиска индексы.
Т.е. имеем например поля f1,f2,f3,f4.
Если пользователь выбрал все 4 параметра для поиска, то запрос будет вида:
WHERE f1 = value1 AND f2 = value2 AND f3 = value3 AND f4 = value4
|
тогда прекрасно подойдет составной индекс по всем четырем полям.
Но если пользователь выбрал только f2 и f4, то для запроса:
WHERE f2 = value2 AND f4 = value4
|
этот индекс уже не будет использован. | |
| |
|
|
| |
|
|
| |
для: Igorek
(23.11.2012 в 16:48)
| | | Это я все понял.
Не важно, что полей фиксированное количество.
Предложенная структура вам все равно подойдет.
У вас есть таблица objects:
id | name | field1 | field2 | field3
|
Замените на 3 таблицы:
objects:
fields:
vals:
obj_id | field_id | value
|
У вас будет всего несколько индексов.
Да, запросы будут сложные, но быстрые. | |
| |
|
|
| |
|
|
| |
для: Sfinks
(24.11.2012 в 02:18)
| | | Интересно, хотя честно говоря смущает, что все параметры будут типа varchar, т.к. значения будут хранится в одном поле vals.value. Контроля значений на уровне БД уже не будет.
Да и, наверное, я бы убрал таблицу fields, а в таблице vals поле field_id сделал типа ENUM (т.к. кол-во полей фиксированное). Хоть какое-то упрощение структуры | |
| |
|
|
