архитектура склада

для этого и сделан тип в таблице характеристик
если задуман как булев будет чекбоксом отображаться
или ты о чем?но выборку неудобно делать будет
(Добавление)
это характеристика formats с текстовым значением
для разных товаров разное значение
что-то не догоняю

я о том, что в той структуре на каждый тип идет своя таблица. в Их структуре сейчас 2 типа - строки и числа, как только этих типов будет больше - таблиц тоже будет больше. Если по каким-то причинам кому-то удобнее использовать юнионы - пусть использует, мне ближе 1 джойн и выбор, на какое поле смотреть.
(Добавление)

Это у вас текст, а у нас каждый поддерживаемый формат отдельно что бы по ним можно было выставить фильтр. Есть свойства-перечисления (как в примере), есть свойства - диапазоны (например, для каких возрастов подходит игрушка 4 - 8, а в фильтре можно спросить возраст ребенка и 6-тилетним детям показывать игрушки, у которых свойство возраст в нужном диапазоне ... но можно все сделать строками, я не спорю)

3 поля и джоин против 1 поля и юниона 3х тбл
не вижу явных преимуществ
посему попробую сначала по своему
(Добавление)
ага...и у вас они связаны с еще одной таблицей если свойство это подразумевает....так?
или как?

Да, связано

можно попробовать
но как этим пользоваться что-то пока не соображу
как будет выглядеть запрос?
ведь тут вроде подзапрос в IF напрашивается ...нет?

мультисвойства идут по отдельной схеме, там все на много сложнее, нам не удалось уложить все в один алгоритм

этого я и боялся
и по какой такой схеме
выбирать дополнительно еще и тип и допрашивать отдельно диапазоны после основной выборки если тип требует?
другого не приходит на ум
(Добавление)
опять же перечисляемый тип можно задать типом фильтра и связать из той же таблицы целых значений и так же сделать добор после основного
пока не буду менять базу
спасибо за мысли

примерно так и есть. Пробовали делать с лишним джойном и group_concat, но вышло медленнее и сложнее

так а что по поводу индексов?
я выше задавал
стоит отдельно индексировать?

я не вижу вопрос про индексы, задай еще раз

индексы проставляются исходя из селектов, которые будут идти.
У тебя составной праймари кей? Если да - на каких полях?
для каких полей?
если у тебя уже стоит первичный ключ на id, то еще и индекс по id не нужен

ставь запятую и учитывай ее в like
с другой стороны может человек и ищет по части слова


и что, рядом есть поле указывающее что это за тип


без проблем перечисляются через запяую
у меня это разные типы чтобы при редактировании товара показывать список чекеров или комбобокс


нафига?


нет проблем с фильтрами даже если формат не отдельно


отож



особого смысла идексировать свойста и значение свойств не вижу

человек ищет либо по названию товара либо если по свойствам то это уже в пределах категории то есть по граниченному числу товаров

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

посмотри в начале темы есть и рисунок и sql файл
я к тому что если первичный ключ составной а выборка идет по 1му то надо ли в этом случае его отдельно индексировать дополнительно?
(Добавление)
для быстрого джойна при просмотре таблицы товаров
как-то все забыли что сначала это будет склад ))

если по первому из составного ключа - не надо. А вообще ответ на такой вопрос занимает куда меньше времени, если прогнать типичный запрос с индексом и без него