scion4581,
В таблицу АВТОМОБИЛИ добавить поле фильтра F1(с индексом), которое будет содержать внешний ключ(FK) смотрящий на таблицу с вашими предустановленными фильтрами:
ТАБЛИЦА F1
id;description
0;1980-1989
1;1990-1999
2;2000-2009
...

scion4581спасибо огромное за ответы!

Суть такова что года выставляются не интервалами, например с 2000 по 2005, а именно выборочно

как захочу - 1980, 2000, 2005 например. и Теперь я создаю фильтр (это отдельная таблица, так как в фильтр можно добавить

название фильтра) и фильтр настраивается по регионам, по маркам, по моделям, по годам. Т .е. я могу закинуть в фильтр например

три региона - Московская обл., Самарская обл., Рязанская.(регионы связаны с машинами через владельцов, суть не в этом),

потом добавляю в фильтр марки тока BMW, Audi , потом добавляю модели в фильтр тока X5(BMW), 100, A5 (Audi). Опять же с этим

все ясно! Просто тут отношения многие ко многим между всеми этими таблицами вида

таблицы:

Регионы Марки Модели

Фильтры

и таблица Фильтры связана с ними многие ко многим таблицей типа Фильтры - Регионы, Фильтры - Марки, Фильтры - Модели!


Ну а как быть с годами??? для них нет отдельной таблицы! Делать отдельную таблицу по такой же схеме или писать в поле типа

TEXT все года через знак, как предложили выше? Спасибо!
Я так понимаю что таблица фильтр нужна для сохранения предыдущих результатов запроса, чтобы последующие запросы совпадающие с фильтром отрабатывались быстро или для быстрого разогрева кэша.
Нужно 3 таблицы
Тбл.АВТО (хранит автомобили)
Тбл.ПОПАДАНИЕ_АВТО_В_ФИЛЬТР (хранит результат)
Тбл.ФИЛЬТРЫ (собствено предустановленные фильтры)
а хранить года нужно по возможности так: 1) Если важна скорость - хранить так чтобы не нужно было делать десериализацию и сразу можно было использовать хранимое значение в программе/запросе 2)Если целей и вариантов использования много и разные, то хранить сериализованно и по подходящему правилу - например можно хранить в строке последовательно без разделителей с заранее известным размером блока 4 символа("198020002005") или еще лучше 2 символа(последние 2 цифры года) например от 1936 до 2035 - еще на 20 лет хватит "800005" - такие строки парсятся быстрее всего(быстрее десериализации, чтения XmlDOM или json, или парсинг любой строки с разделителями)

scion4581Malter, мне что есть смысл сохранять результаты по фильтру в отдельную таблицу? у меня данные постоянно меняются, т.е. люди оформляют заказы используя данные из таблиц о машинах, и фильтр тоже использует эти данные. А ищутся заказы по фильтрам, которые постоянно добавляются. Просто если данные автомобилей содержатся в разных таблицах, а вот год это просто поле.
хотя алгоритм настройки фильтра так же как и с другими характеристиками авто предусматривает множественный выбор по годам.
Если у вас много запросов, то естественно состояние фильтров будет часто повторятся от пользователя к пользователю и их резонно хранить в горячем кэше.
Год это просто поле - оно и должно быть просто полем, точно также как и все внешние ключи(FK) смотрящие на таблицы с другими характеристиками тоже просто поля. Только в случае с характеристиками хранящимися в отдельной таблице вам нужно сначала определить первичные ключи а потом уже использовать их в качестве условия в основной таблице, то в случае с полем ГОД вы сразу используете его в условии запроса к основной таблице. Но на самом деле оперируя фильтром пользователь уже оперирует списками ключ-значение и выбирая значения в фильтрах в запрос уже передаются ключи по которым строится условие выборки из основной таблицы АВТО.
scion4581именно заказы постоянно добавляются и результат кеширования будет постоянно меняться я так полагаю? Интересует именно более подходящее решение в этом конкретном случае хранения данных т.е. в базе а не файлах типа xml или что то в таком духе.
Результат кеширования для конкретного фильтра будет меняться только при добавление записей в таблицу АВТО попадающему под этот фильтр. При добавлении новой записи в АВТО нужно делать сверку на совпадениями характеристик Авто с набором характеристик в Фильтрах и если хоть одна характеристика в фильтре совпадает то нужно обновлять кэш для этого фильтра, но такой подход очень ресурсоемкий - гораздо лучше актуализировать кэш периодически - например 1 раз в 5 часов, а те АВТО которые добавляются в течение этих 5 часов выбирать из БД обычным SQL запросом с небольшим дополнительным условием в котором указано что выбирать нужно только из тех записей ID у которых больше XXXXX, а этот XXXXX и есть ID последней добавленной в кэш записи, а все что больше еще не добавлены - так будет очень быстро работать.
Но тут есть еще один нюанс - размер КЭША, время агрегации данных для Кэша(в инкрементальной модели(where ID>XXXXX) как описано выше это не существенно) и реальная насущная необходимость в кешировании именно всего фильтра - скорее всего достаточно будет кешировать только по 3 пунктам характеристик(по самым многочисленным и неотвратимоиспользуемым: Модели, Год, Что-то_еще) а уже из этих закешированных данных уточнять запрос по оставшимся мелким характеристикам.
Если будете используете кэширование только по основным характеристикам, то удобано для горячего КЭША использовать временные таблицы в оперативной памяти(mysql memory) т.к. можно будет использовать уточняющие SQL Select запросы прямо из них и дополнять их можно будет одним запросом не гоняя данные между БД и Приложением.
А вообще для кэша ключ-значение лучше использовать специализированные решения вроде Memcashed.

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

действительно фильтры могут повторяться от пользователя к пользователю. Насчет поля ГОД, я просто к чему спрашивал, у меня в

фильтре могут быть выборочные года, поэтому если с таблицами других характеристик ясно, делать связывающие таблицы фильтров

и таблицы характеристик, и в них писать множественный выбор характеристик для одного фильтра, то вот с годами я так и не понял

как лучше хранить присутствие в одном фильтре нескольких годов! вот сама суть вопроса была.

Но все равно очень признателен за просвещение.
Если я правильно понимаю, то вы хотите хранить значения фильтра так чтобы этот фильтр можно было найти одним sql запросомт.
Например можно хранить года в строке - каждый год 4 символа, и всегда располагать годы по возрастанию - "198120052014" и в условии запроса делать where YEARS="198120052014" ИЛИ использовать 2 символа года "810514".

А кроме года вам нужно хранить и другие характеристики вроде ЦВЕТ и делать так "красныйчерныйбаклажан" впринципе тоже можно.
Достоинства этого способа очевидны, как и недостатки.
Но у вас специфика такова что для каждого условия фильтра существует конечное и достаточно небольшое количество вариантов, Поэтому я бы в этом случае использовал битовые масски - т.е. например есть года с 1950 по 2030 (81 года) и выбранному элементу фильтра ГОД будет соответствовать битовая маска "0000000000000000000010000000000000010010000000011" в которой каждый год это один символ по возрастанию от 1950 до 2030. Так же сделал бы и для всех остальных элементов фильтра(соответственно для каждого элемента нужен справочник с фиксированными ID).
В качестве оптимизации можно хранить не всё значение битовой маски, а только часть от начала до последнего выбранного значания(например если выбраны годы 1950,1952,1960, то достаточно хранить "10100000001" т.к. остальные будут нулями).
Еще неплохой оптимизацией было бы разделение битовой маски на 2 поля в которых бы хранились маски по принципу наиболее/наименее часто используемых условий (например есть 100 цветов, но на практике в 95% случаев используется только 20 из них - вот и делим битовую маску на 2 части по 80 и 20 символов - т.е. в 95% случаем первая часть из 80 символов будет пустая и ее не придется даже включать в условие sql запроса. Также по аналогии следует с ГОДАми (например наиболее часто используемы годы это от 1990 до 2030), брэндами, марками и т.д.

scion4581Malter, спасибо за ответ! Нет цвет могут писать от балды, в фильтре он не указывается. Да все верно, нужно так чтобы одним

запросом выводился не фильтр а все заказы по фильтру, т.е. автомобили которые были занесены в заказы. Данные авто для заказов

и фильтров используются с одних таблиц, просто если в заказе может быть один год у машины или например только один бренд авто,

то у фильтра их много может быть, например я выставил для фильтра 3 или 4 бренда и несколько годов 2004, 2001, 1980 и вижу

из кучи заказов только те что совпадают по фильтру.

"я выставил для фильтра 3 или 4 бренда и несколько годов 2004, 2001, 1980 " и далее вы формируете из этих данных sql запрос



?
Тогда в чем смысл исходного вопроса?

Я предлагал вам хранить фильтр и результаты запроса в виде ключ->значение в двух таблицах "ФИЛЬТРЫ"(выбранные пользователями условия) и "РЕЗУЛЬТАТЫ"(результаты выборки из табл.АВТО по конкретным фильтрам), где "РЕЗУЛЬТАТЫ" хранили бы связь с "ФИЛЬТРЫ" и "АВТО". И уже для данных из таблицы РЕЗУЛЬТАТЫ использовать быстрый кэш.

Кот МатроскинMalterЯ предлагал вам хранить фильтр и результаты запроса в виде ключ->значение в двух таблицах "ФИЛЬТРЫ"(выбранные пользователями условия) и "РЕЗУЛЬТАТЫ"(результаты выборки из табл.АВТО по конкретным фильтрам), где "РЕЗУЛЬТАТЫ" хранили бы связь с "ФИЛЬТРЫ" и "АВТО". И уже для данных из таблицы РЕЗУЛЬТАТЫ использовать быстрый кэш.

Вы представляетее себе размер таблицы результатов хотя бы для системы из 3 фильтров по 30 возможных элементов?

Например 100 марок авто, 50 лет, и 20 цветов = 100*50*20*30шт=100тыс*30шт, вносим поправку на непересекаемость всех элементов со всеми - где-то на порядок меньше по фильтру и на на 2 порядка меньше по результатам, а также вносим поправку на то что в одном фильтре могут участвовать несколько значений из одного поля т.е. на 5 порядков(условно) больше - Итого 1млрд фильтров и всего ~3тыс найденых результатов, а если автомобилей будет 1млн, то результатов выборки будет 100млн(средний максимум на 1 запись в фильтре 10тыс).
Но это все оторвано от реальности - в реальности нужно считать физически возможное возникновение новых фильтров исходя из количества пользователей, времени и т.д - например будет 1млн сеансов и каждый создаст по 5 фильтров(в среднем), то получится 10млн созданных фильтров из которых 80% будут повторятся т.е. ~1+1млн записей за 1 млн сеансов. Если взять в среднем длину записи в фильтрах в 100байт(писал ранее если использовать битовые маски) для хранения наборов фильтра, то получим таблицу в ~200Мб( и это на 1млн сеансов). И размер сериализованных результатов выборки потянет на ~1,2ГБ(если в базе 1млн авто и в среднем результате выборки 100 записей то это 200млн идентификаторов по 6Байт("999999")) - здесь речь идет о хранении результатов выборки в виде сериализованного списка id - их можно актуализировать через некоторые промежутки времени - об этом я выше писал.
На абсолютную правоту не претендую.

Кот МатроскинMalterпропущено...


Например 100 марок авто, 50 лет, и 20 цветов = 100*50*20*30шт=100тыс*30шт,

Cтоп-стоп. Возможных сочетаний из 100 марок машин (в фильтре же может быть отмечено несколько марок)- уже 2^100, т.е. примерно 10^30. Больше даже и не надо ничего ;)
Дальше прочитайте - там об этом как-раз и написано.

Кот МатроскинMalterпропущено...

Дальше прочитайте - там об этом как-раз и написано.

Там написаны какие-то странные предположения и расчеты непонятно чего.
также вносим поправку на то что в одном фильтре могут участвовать несколько значений из одного поля т.е. на 5 порядков(условно) больше - Итого 1млрд фильтров

Как Вы посчитали что на 5 порядков? я выше показал что число возможных значений только одного фильтра превосходит Вашу оценку на 20 порядков.

И даже если взять (непонятно откуда взявшийся) миллиард фильтров в среднем по 100 элементов - Вы считаете что держать кэш
из миллиарда выборок по 100 элементов выгоднее, чем считать ее на миллионе записей каждый раз заново?
Особенно интересен случай добавления нового (или обновления старого) элемента в основной таблице - система будет вынуждена прошерстить миллиард фильтров чтобы оценить, из каких выборок надо его исключить, а в какие добавить?

Но это все оторвано от реальности - в реальности нужно считать физически возможное возникновение новых фильтров исходя из количества пользователей, времени и т.д - например будет 1млн сеансов и каждый создаст по 5 фильтров(в среднем),
Т.е. Вы еще и в процессе работы эти фильтры хотите добавлять? Строится отчет по новому фильтру - и отчет (!) начинает писать в базу свой фильтр и свою выборку?

Имхо по совокупности предлагаемая архитектура - эталон того как делать не надо.
Еще дальше читайте )) там написано.
Речь как раз о том что фильтры появляются в процессе работы и их создают пользователи.
А вообще стоит почитать всю переписку с начала - все уже написано.