варианты с динамическим списком:
extra_param
id param name
extra_param_vs_group
id_param id_group
extra_param_value_vs_user
id_param id_user value
самое нормализованное и целостное решение
-~{}~ 17.12.08 04:12:
а я бы в одну таблицу все запихнул. ничего страшного, что в группе А будет стоять значение NULL в одном из наборов полей.
зачем проверка на NULL? мета-таблицы со связями один-ко-многим между user_group и profile_field будет достаточно.
характеристика может принадлежать только одной группе
таблица для доп. характеристик типа:
id | user_id | param_name | value
неудобно управлять списком и получать инфомрацию о пользователях и их характеристиках
option
optionis, optionname
optionval
optionid, mandantid, value
то же самое, но немного проще получить весь список характеристик
хранения доп характеристик в serialize или xml-виде
получить пользователей и их характеристики удобно, но управлять списком - нет
но у человека наверняка список характеристик фиксированный, поэтому имхо лучший вариант, не раз упоминавшийся - все в одной таблице
common_user: id, [param1, param2,...]
user_type1: id, [extra_param1, extra_param2,...]
user_type2: id, [extra_param1, extra_param2,...]
user_type3: id, [extra_param1, extra_param2,...]
неудобно извлекать список всех пользователей со всеми характеристиками, а экономия на NULL полях неизвестно велика ли
Делаем осевую таблицу. К ней крепим кросс таблицу, а через нее уже делаем связку с остальными тремя.
а в этот вариант как-то не вьехал
