Ответ 1
В других ответах были изложены плюсы и минусы различных вариантов.
Я считаю, что ваш вариант 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 |
+------+---------+------------+--------------------------+---------------------+
Из этих таблиц видно, что некоторые пользовательские настройки, которые могут быть определены, - это "Любимый цвет", "Максимальный размер позиции" и "Минимальный лимит предмета". "Любимый цвет" - это список буквенных букв. Пункты min и max - это число с допустимыми значениями диапазона. Столбец SETTING.constrained определяет, выбирают ли пользователи из связанного ALLOWED_SETTING_VALUE или им нужно ввести USER_SETTING.unconstrained_value. Графический интерфейс, который позволяет пользователям работать со своими настройками, должен понять, какой вариант предложить и как обеспечить соблюдение ограничений SETTING.data_type и min_value и max_value, если они существуют.
Используя эту конструкцию, вы можете приводить в таблицу допустимые параметры, включая достаточное количество метаданных, чтобы обеспечить соблюдение некоторых рудиментарных ограничений/проверок на значения, выбранные (или введенные) пользователями.
EDIT: Пример запроса
Вот пример 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.
