[laimas]

я попытался поискать

http://www.mysql.ru/docs/man/SET.html

То есть, битовое значение каждого множества, это 1 в соответствующем разряде.

ничего не понял

Если записать битовые значения (двоичное представление) SET для a, b, c, d, e, f и их десятичные значения (десятичное представление), то получим:

a = 000001 = 1
b = 000010 = 2
c = 000100 = 4
d = 001000 = 8
e = 010000 = 16
f = 100000 = 32

Легко заметить, что десятичные значения равны 2 в степени n, где n число от 0 до предела зависящего от разрядности системы, то есть 32 или 64. Поэтому в распоряжении могут быть 32 или 64 бита, значений которые может содержать множество SET.

В основе все этого, как в общем и вашего мощного компьютера, лежит базовый набор логики: И, ИЛИ, НЕ (отрицание). На базе которых строятся более сложные логические элементы.

Битовая операция ИЛИ, это логическое сложение (дизъюнкция), которое соответствует логике: на выходе (out) будет логическая 1 если на любом из ее входов (a, b) будет логическая 1, иначе на выходе будет логический 0. Количество входов может быть каким угодно.

a b out
0 0 0
1 0 1
0 1 1
1 1 1

Если, к примеру, в наборе a, b, c, d, e, f будут выбраны значения a, c, e и f, то значение набора будет равно: двоичное - 110101, десятичное - 53, согласно логическому сложению:

000001
000100
010000
100000
--------
110101

Логическое И, это логическое умножение (конъюнкция), и в отличии от ИЛИ на ее выходе будет логическая 1 только в том случае, если на всех ее входах будет логическая 1. Логическое И удобно в операциях маскирования, например для выделения определенной части входов устройства, просто числа.

Вкупе этим базовым операциям стоит упомянуть и операцию ИСКЛЮЧАЮЩЕЕ ИЛИ, которая удобна для управления отдельными битами - установить/сбросить бит.

В общем это и вся "арифметика" для понимания. Тем более, что вам не придется все это "считать в уме", вы либо оперируете текстовым значением множества, либо числовым, а представление числового значения как десятичное, это автоматически сделает SQL.

Что касается применения SET. Разберем это на примере, он есть в архиве с дампом sql таблиц. Создайте тестовую базу на локальном сервере, импортируйте таблицы, и запустите индексный файл. В нем все, и серверная часть, и клиентская. Работа с базой написана под PDO, в котором по умолчанию выборка из базы, это строка в виде объекта. Можете исправить на свое подключение и работать как с ассоциативным массивом, это не суть важно, главное сами запросы.

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

В примере один товар помещен в таблицу товаров, и только товары имеют уникальный идентификатор. Кроме него таблица содержит название и производителя товара, и его описание.

Характеристики товара содержатся в связанной таблице характеристик. В примере все упрощено - две характеристики товара, материал и качество, содержатся в одном наборе SET. Первые четыре значение, это материал, последние три, это качество. Упрощение не просто ради простоты, а и для того чтобы показать как можно оперировать битовым набором.

Каждому из наборов двух характеристик материал/качество соответствуют две характеристики - цена и вес. При выборке товара из базы, наборы характеристик (ключ options), это массивы (цена, вес), первичными ключами которых является числовые значение их набора материал/качество.

Запросом клиенту отдаются и подготовленные данные для двух отдельных списков. Сразу замечу, что можно было бы не получать числовые значения для списка Качество так как в коде, можно было не сдвигать бинарные данные значений этой характеристики, можно было очистить по маске четыре младших разряда, то есть вес значений остался бы тем что что и в SET. Сделано так, чтобы показать вариации, далее об этом будет сказано.

Для формирования данных списка, для списка материалов берутся 4 младших разряда по битовой маске 1111 (fabric & 15), а для списка качества значение сдвигается вправо на 4 разряда (fabric >> 4). Соответственно тексты для каждого из значений получаются либо справа, либо слева от запятой (SUBSTRING_INDEX) текстового набора каждого из наборов материал/качество. В конечный массив списков помещаются только те характеристики, которые есть у данного товара. В каждый список характеристик передается и величина сдвига значения.

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

При выборе характеристик в списках, происходит обратная операция - выбранное значение каждого списка сдвигается влево на указанное число разрядов , после чего они складываются. По этому значению как по свойству объекта data извлекается цена и вес этого набора.

При добавлении в корзину такой же обратной операцией получается битовый набор характеристик материал/качество, который пишется в корзину. При извлечении из корзины, по этому значению из таблицы характеристик извлекается их текстовые значения.

Почему сдвиги (вариации, о чем было выше) и что из того, что каждое значение SET подчинено 2 в степени n? Можно ведь и не обязательно SET использовать, но можно использовать принцип такого набора множества. Если держать характеристики как обычные записи в таблице - идентификатор, текст, и формировать их идентификаторы не средствами SQL полем с автоинкрементом, а управлять этим процессом, имея идентфикаторы с шагом 2 в степени n, то таким набором данных можно можно оперировать как и SET. В этом случае нужно только определить место каждой такой описанной характеристики в общем наборе, а сдвиг значений каждого набора будет определяться суммой количества значений всех предыдущих характеристик.