KriziunУ кого какие идеи по реализации структуры?количество групп/опций может меняться или жёстко задано раз и навсегда? эти опции по отдельности потом где-то ещё в работе базы участвуют или всё, что с ними надо делать - хранить и выдавать целыми блоками?
KriziunТак же результатом выборке из базы нужно получить удобную структуру для того, чтобы при выборе одной из опций можно было заблокировать не связанные с ней (не доступные) опции во всех остальных группах .выделенное - задача интерфейса, никак не БД
максимум, что тут можно требовать от БД - выдать список "разрешительно-запретительных" правил

Kriziun, а что тогда думать, трясти надо :)

groups:{id,name,...}
options:{id,idgroup,name,...}
users:{id,name,...}
selections:{iduser,idoption,flag,...}

Обработку (запись/выдачу наборов, ну хотя бы запись) - через хранимки, там же и проверять валидность введённых данных.



Как хранить правила - ну, допустим, так
rules:{id,name}
rules_details:{idrule,idoption,rtype,value}
(ид правила, ид опции,исходное условие/результат, значение)
Т.е., например, "при выборе опции 1.1 могут быть не доступны опции 2.2-2.n и к примеру опция 3.1" запишется как
idruleidoptionrtypevalue1'1.1'111'2.2'20............1'2.n'201'3.1'20(вместо идшников пишу имена опций , "не доступны" трактую как "отключены/занулены")

KriziunЭто понятно, вопрос в том как минимизировать и/или упростить, обрабатываемый в дальнейшем, резалтсет, что напрямую зависит от структуры.Не зависит. Нагрузка на сервер при формировании нужного резалтсета - да зависит, но его самого можно из любых данных получить. Вопрос в том, в каком виде он будет нужен вам и прочим обработчикам этих данных :)

Kriziunрезультат выбранного набора опций - не список их id а именно произвольное число введенное пользователем именно для данного набора.нашли проблему...
selection:{id,iduser,произвольное_число,...}
selection_detail:{idselection,idoption,flag,...}