Хранение комбинаций?

Question

[Hidralisk]

Не уверен что точно сформулировал вопрос - но суть такова.
Предположим есть некий объект у которого 10 полей и в каждом поле может быть 100 различных уникальных значений.
Например поле ЦВЕТ может иметь 100 значений, следующее поле РАЗМЕР может иметь 100 значений и тд.
Сотруднику нужно дать возможность задавать некие комбинации. Например он может выставить что для ЦВЕТ = красный и РАЗМЕР = 20мм и ПЛОТНОСТЬ = 5 мы задаем некую скидку в 5%. Эти комбинации нужно хранить в базе. Заранее не известно сколько их будет .
Может быть скидка в 5% будет предоставляться вообще для всех возможных комбинаций, а может для одной а может и для 10000. Сотрудник может например указать для 5-ти полей ALL и включить все значения. Подскажите как лучше хранить такие данные?

Comments

[Andry]

На что упор в вопросе? В конкретно больших объемах данных и как это все уместить хотя бы на мегасервер и как-то обработать. Или же числа с размерами даны с потолка и мы думаем над организацией скидок в интернет магазине?

[Hidralisk]

Андрей, Для организации скидок для интернет магазина , но вопрос интересен и для больших объёмов.
Вообще смысл вопроса в том как хранить комбинации если ты заранее не знаешь вообще сколько их будет, так как их задаёт сотрудник.
Например он может выбрать все поля в ALL и соответсвенно будет 100*100*100*100.... кобминаций. это миллион строк.
Как их хранить? Генерировать все возможные комбинации? Суть в том что он их может менять как хочет.

Answer 1

[anikavoi]

если длина предельной комбинации влезает в разрядность максимального целого типа бд, то банально:
3-й цвет из 10 6-й размер из ста, 2-я возрастная группа из десяти:
1052... почему не 2063? потому что от нуля считаем.

Если же варианты никуда не влезут типа: 356 вариант 4789065 схемы 195 подгруппы 56 группы 9879879 вектора 987987987 простраства итд итп, то... записываем в строку через запятую и делаем от нее хеш... любой толковый. Коллизии - обрабатываем отдельно.

ANY_HFUNC("356,4789065,195,56,9879879,987987987");

https://en.wikipedia.org/wiki/List_of_hash_functions

Answer 2

[xmoonlight]

Формулу расчёта скидки с именами полей и критериями для конкретной позиции храним в отдельной таблице.

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

Comments

[Hidralisk]

Ну вопрос в том как именно хранить эти критерии.
Сотрудник может установить ALL для всех критериев и если у тебя 20 видов критериев по 100 значений это 100*20 комбинаций .
Генерировать их в базе?
Хранить массивами и исключениями?
А может и сделать одну запись, а может и сделать что для РАЗМЕР -ALL а остальные поля выборочно.

[xmoonlight]

Hidralisk, Создаём групповые критерии.
Ставим доп. тип поля в таблице записей критериев (один из): "ALL", "EXCEPT" и "IN" и перечисляем в них нужные поля.

Пример (скидка 5% для всего, кроме: женского И (красного ИЛИ белого) ):
Тип поля: EXCEPT
Критерий: {Цвет:[Красный, Белый], Пол:[Ж]}
Скидка: -5%