Дизайн на база данни за потребителски настройки

Други отговори умело очертават плюсовете и минусите на различните ви опции.

Вярвам, че вашият вариант 1 (чанта за имущество) е най-добрият цялостен дизайн за повечето приложения, особено ако вградите някои защити срещу слабостите на чантите с имущество.

Вижте следното ERD:

В горния ERD, USER_SETTING таблицата е много подобна на OP. Разликата е, че вместо varchar Code и Value колони, този дизайн има FK към SETTING таблица, която дефинира допустимите настройки (Кодове) и две взаимно изключващи се колони за стойността. Едната опция е поле varchar, което може да приема всякакъв вид въвеждане на потребителя, а другата е FK към таблица с законни стойности.

SETTING таблицата също има флаг, който показва дали потребителските настройки трябва да бъдат дефинирани от FK или чрез неограничен вход на varchar. Можете също да добавите data_type към SETTING да кажете на системата как да кодира и интерпретира USER_SETTING.unconstrained_value . Ако желаете, можете също да добавите SETTING_GROUP таблица, за да ви помогне да организирате различните настройки за поддръжка от потребителя.

Този дизайн ви позволява да управлявате правилата за това какви са вашите настройки. Това е удобно, гъвкаво и лесно за поддръжка, като същевременно се избягва безплатно за всички.

РЕДАКТИРАНЕ: Още няколко подробности, включително някои примери...

Имайте предвид, че ERD, по-горе, е допълнен с повече подробности за колоните (стойности на диапазона на SETTING и колони на ALLOWED_SETTING_VALUE).

Ето някои примерни записи за илюстрация.

SETTING:
+----+------------------+-------------+--------------+-----------+-----------+
| id | description      | constrained | data_type    | min_value | max_value |
+----+------------------+-------------+--------------+-----------+-----------+
| 10 | Favourite Colour | true        | alphanumeric | {null}    | {null}    |
| 11 | Item Max Limit   | false       | integer      | 0         | 9001      |
| 12 | Item Min Limit   | false       | integer      | 0         | 9000      |
+----+------------------+-------------+--------------+-----------+-----------+

ALLOWED_SETTING_VALUE:
+-----+------------+--------------+-----------+
| id  | setting_id | item_value   | caption   |
+-----+------------+--------------+-----------+
| 123 | 10         | #0000FF      | Blue      |
| 124 | 10         | #FFFF00      | Yellow    |
| 125 | 10         | #FF00FF      | Pink      |
+-----+------------+--------------+-----------+

USER_SETTING:
+------+---------+------------+--------------------------+---------------------+
| id   | user_id | setting_id | allowed_setting_value_id | unconstrained_value |
+------+---------+------------+--------------------------+---------------------+
| 5678 | 234     | 10         | 124                      | {null}              |
| 7890 | 234     | 11         | {null}                   | 100                 |
| 8901 | 234     | 12         | {null}                   | 1                   |
+------+---------+------------+--------------------------+---------------------+

От тези таблици можем да видим, че някои от потребителските настройки, които могат да бъдат определени, са Любим цвят, Максимален лимит на артикула и Мин. Любимият цвят е списък с букви и цифри. Минималните и максималните граници на артикули са числови с зададени допустими стойности на диапазона. SETTING.constrained колоната определя дали потребителите избират от свързания ALLOWED_SETTING_VALUE s или дали трябва да въведат USER_SETTING.unconstrained_value . GUI, който позволява на потребителите да работят с техните настройки, трябва да разбере коя опция да предложи и как да наложи както SETTING.data_type и min_value и max_value ограничения, ако съществуват.

Използвайки този дизайн, можете да зададете в таблицата допустимите настройки, включително достатъчно метаданни, за да наложите някои елементарни ограничения/проверки за здравина на стойностите, избрани (или въведени) от потребителите.

РЕДАКТИРАНЕ:Примерна заявка

Ето малко примерен SQL, използващ горните данни за изброяване на стойностите на настройките за даден потребителски идентификатор:

-- DDL and sample data population...
CREATE TABLE SETTING
    (`id` int, `description` varchar(16)
     , `constrained` varchar(5), `data_type` varchar(12)
     , `min_value` varchar(6) NULL , `max_value` varchar(6) NULL)
;

INSERT INTO SETTING
    (`id`, `description`, `constrained`, `data_type`, `min_value`, `max_value`)
VALUES
    (10, 'Favourite Colour', 'true', 'alphanumeric', NULL, NULL),
    (11, 'Item Max Limit', 'false', 'integer', '0', '9001'),
    (12, 'Item Min Limit', 'false', 'integer', '0', '9000')
;

CREATE TABLE ALLOWED_SETTING_VALUE
    (`id` int, `setting_id` int, `item_value` varchar(7)
     , `caption` varchar(6))
;

INSERT INTO ALLOWED_SETTING_VALUE
    (`id`, `setting_id`, `item_value`, `caption`)
VALUES
    (123, 10, '#0000FF', 'Blue'),
    (124, 10, '#FFFF00', 'Yellow'),
    (125, 10, '#FF00FF', 'Pink')
;

CREATE TABLE USER_SETTING
    (`id` int, `user_id` int, `setting_id` int
     , `allowed_setting_value_id` varchar(6) NULL
     , `unconstrained_value` varchar(6) NULL)
;

INSERT INTO USER_SETTING
    (`id`, `user_id`, `setting_id`, `allowed_setting_value_id`, `unconstrained_value`)
VALUES
    (5678, 234, 10, '124', NULL),
    (7890, 234, 11, NULL, '100'),
    (8901, 234, 12, NULL, '1')
;

И сега DML за извличане на потребителски настройки:

-- Show settings for a given user
select
  US.user_id 
, S1.description 
, S1.data_type 
, case when S1.constrained = 'true'
  then AV.item_value
  else US.unconstrained_value
  end value
, AV.caption
from USER_SETTING US
  inner join SETTING S1
    on US.setting_id = S1.id 
  left outer join ALLOWED_SETTING_VALUE AV
    on US.allowed_setting_value_id = AV.id
where US.user_id = 234

Вижте това в SQL Fiddle.