Mysql и дополнительные поля или новая таблица

Можно было сделать всего одно дополнительно поле типа SET с возможными значениями ('prop1','prop2',...,'propN').

На это поле повесить индекс.

Поиск по значениям в этом поле делается оператором find_in_set().

Красиво, быстро, наглядно.

Спасибо. Почитаю. Ооднако никогда с такими типами не работал, не знаю на сколько они хороши.

Кстати, а как при обычной выборке получить данные и с ними работать?

относительно чего быстро? set хранится как набор битов. индекса, который локализует выборку записей с конкретным свойством по нему не сделаешь.

Да, вы правы.

Значит уточню: быстрее в разработке ;)

Данные из поля типа SET? Они возвращаются в виде строки, представляющей набор значений сета разделенных запятыми

то есть, поиск по одному/нескольким параметрам или же будет поиск по всем одновременно? Во втором случае проще было бы в одном поле хранить и по нему индекс сделать.

а. для селекта что бы получить свойства

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

Miracle, тогда я бы посоветовал бы вынести свойства в отдельную таблицу

Сделать индекс, но не отдельные на 1 и 2 столбец, а двойной сразу на 2 первых столбца. А данные из это таблицы доставать отдельным запросом.

То есть, вариант немного отличается от ваших 2, если что-то будет непонятно, тогда уже позже отпишу, а сейчас побежал а стол :)

я понял. но, не совсем понятны две вещи.

а. не правильней ли сделать доп таблицу сразу на все prop?

gr_id prop_1 prop_2 ... prop_Х (почему то мне кажется что это все же запрос по проще, хоть и места будет больше занимать)

б. value 1 и 0 мне кажется лишние, просто есть есть, тогда 1 если нет тогда нет, просто удалять свойство.

Но самое важное, почему вы решили предложить именно такой способ. Меня интересую плюсы :). Экономия места? Это несомненно плюс, но в тоже время 1 лишний запрос а это еще больших минус. А так как у меня в основном СЕЛЕКТЫ и причем их много, то теперь в место одного надо будет делать их два!

Сейчас понял, что возможно не до конца понял задачу. Данные будут доставаться только по prop_x и их комбинациям, и в запросах в where не будет поиска по id, или же сортировки по id? Если не будет, то тогда будем думать вариант другой.

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

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

почему не сделаешь. сделаешь!

к примеру

есть свойства а, б , с , д

вот если я хочу выбрать 1 и 3 тогда (считаем задом наперед, Д, С ,Б , А -> 0101 = 5) для выборки достаточно сделать следующее props_field_set & 5

Пока решение понравилось.