在设计用于存储用户设置的表格时，以下哪个选项（如果有）被认为是最佳实践？
（选项1）
USER_SETTINGS
-Id
-Code (example "Email_LimitMax")
-Value (example "5")
-UserId
(选项2)
为每个设置创建一个新表，例如，通知设置需要创建：
"USER_ALERT_SETTINGS"
-Id
-UserId
-EmailAdded (i.e true)
-EmailRemoved
-PasswordChanged
...
...
"USER_EMAIL_SETTINGS"
-Id
-UserId
-EmailLimitMax
....
（选项3）
"USER"
-Name
...
-ConfigXML
其他答案已经详细阐述了您各种选项的利弊。
我认为对于大多数应用程序来说，您的选项1（属性包）是最佳设计，特别是如果您增加了一些保护措施来防范属性包的弱点。
请参阅以下ERD：
在上面的ERD中，USER_SETTING表与OP的非常相似。区别在于，这个设计没有varchar Code和Value列，而是有一个指向SETTING表的FK，该表定义允许的设置（代码）和两个互斥列的值。其中一个选项是一个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 |
+------+---------+------------+--------------------------+---------------------+
使用此设计，您可以驱动数据表中的允许设置，包括足够的元数据来强制执行一些基本的约束/合理性检查所选值（或输入）的用户。
编辑：示例查询
这里是使用上述数据列出给定用户ID的设置值的一些示例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 上查看此内容。
USER表上的列）。如果你的应用程序更加结构化，使用属性包结构不是一个好主意。 - Joel Brown方案一（如注明的“属性袋”）容易实现，几乎没有前期分析。但它有很多缺点。
如果您想限制 UserSettings.Code 的有效值，则需要一个辅助表来列出有效标记的列表。 因此，您要么（a）没有对 UserSettings.Code 进行验证 - 您的应用程序代码可以将任何值转储到其中，错过捕获错误的机会，或者要在新的有效标记列表上添加维护。
UserSettings.Value 可能具有字符串数据类型，以适应可能输入其中的所有不同值。 因此，您失去了真正的数据类型 - 整数、布尔、浮点等，以及 RDMBS 在插入不正确的值时进行的数据类型检查。 再次，您自己引入了潜在的 QA 问题。 即使对于字符串值，您也失去了对列长度的约束能力。
无法根据 Code 在列上定义默认值。 因此，如果您想让 EmailLimitMax 默认为 5，则无法这样做。
类似地，无法在 Values 列上放置 CHECK 约束以防止无效值。
属性袋方法失去了 SQL 代码验证。 在命名列方法中，查询“从 UserSettings 中选择 Blah where UserID = x”将在 Blah 不存在时获得 SQL 错误。 如果 SELECT 在存储过程或视图中，则在应用 proc / view 时就会出现错误 - 比代码进入生产时间提前很多。 在属性袋方法中，您只会得到 NULL。 因此，您失去了数据库提供的另一个自动 QA 功能，并引入了可能无法检测到的错误。
如注明的，查找适用于多个标记的条件的 UserID 的查询变得更加困难 - 它需要为每个被测试条件加入一次表联接。
不幸的是，属性包邀请应用程序开发人员将新代码只是粘贴到属性包中，而不分析它在应用程序的其余部分中如何使用。对于大型应用程序而言，这成为“隐藏”属性的来源，因为它们没有经过正式建模。这就像使用纯标记-值而不是命名属性来进行对象模型一样：它提供了一种逃逸阀门，但您会错过编译器在强类型、命名属性方面所给予的所有帮助。或者像在生产XML时没有模式验证。
列名称方法是自我说明的。表中的列列表告诉任何开发人员可能的用户设置。
我曾经使用过属性包； 但只是作为一个逃生口，我经常后悔。我从未说过“天啊，我希望我把显式列作为属性包”。
很难评估“最佳”是因为它取决于你想运行的查询类型。
选项1（通常称为“属性包”，“名称值对”或“实体-属性-值”或EAV）使存储预先未知架构的数据变得容易。但是，它使得运行常见的关系查询变得困难或有时不可能。例如，想象一下运行相当于
select count(*)
from USER_ALERT_SETTINGS
where EmailAdded = 1
and Email_LimitMax > 5