SystemSettings的表设计，最佳模型答案

【问题标题】：Table Design For SystemSettings, Best ModelSystemSettings的表设计，最佳模型
【发布时间】：2011-01-25 02:14:42
【问题描述】：

有人建议移动一个充满设置的表格，其中每列是设置名称（或类型），行是客户及其各自的设置。

ID |管理员 |图像路径
------------------------------
12 | 1 | \路径\到\图像
34 | 0 | \path\to\images

这样做的缺点是每次我们想要一个新的设置名称（或类型）时，我们都会更改表（通过 sql）并添加新的（列）设置名称/类型。然后更新行（以便每个客户现在都有该设置的值）。

新的桌子设计方案。建议有一个用于设置名称的列和另一个用于设置的列。
身份证 |设置名称 |设置值
----------------------------------------
12 |管理员        | 1
12 |图像路径   | \路径\到\图像
34 |管理员        | 0
34 |图像路径   | \path\to\images

他们提出的观点是，添加新设置就像对行的简单插入语句一样简单，无需添加列。

但是第二种设计感觉有些不对劲，看起来很糟糕，但我无法提出任何反对意见。我错了吗？

【问题讨论】：

标签： sql database-design normalization denormalization

【解决方案1】：

这是“Entity Attribute Value”架构的变体（Joel 和 random SO question）

它有一些优点和更多的缺点，而且它几乎肯定会以眼泪收场。

【讨论】：

我认为在设置上使用 EAV 是可以的。围绕 EAV 设计完整的数据库是一个完全不同的故事，而不是 OP 所要求的。但是从您的角度来看，我看不出文档数据库有多么根本的不同，我看不出为什么使用它们也一定会流泪。
@Johannes Rudolph：对于简单的系统设置表，可以。就像 web.config 中的 appsettings 一样。但是，与 web.config 一样，您可以使用专用部分进行更复杂的设置：您无需扩展 appsettings。最终，情况会变得更糟，因为有人会认为“这是个好主意”。话说，我用过但你要小心……
感谢提醒，这是 EAV 的（粗略）版本，在链接和谷歌之间，我应该得到一些东西。参照完整性似乎确实存在一些问题。比如创建一个设置 DefaultReportID，10 时在 1 到 9 的 Report Table 中存在。
discuss.joelonsoftware.com/default.asp?design.4.331499.15 - 此链接已失效

【解决方案2】：

第二种方法实际上类似于字典。由于您提到的原因，我发现这对于我正在开发的应用程序来说是一个更方便的选择。这种方法有一些注意事项，因此您需要小心：

保持密钥字符串不变，切勿重命名。
确保每次检索设置字典时都将其更新到最新版本（通常通过添加键和设置默认值/提示用户）。
混合字符串和例如十进制数据，您需要选择一个或提供多个可为空的列，以便您可以以适当的格式存储数据。将元数据保存在某个地方。
处理字典的代码应该以强类型的方式包装它，永远不要将它公开为真正的字典（在数据结构的意义上），而是提供一个类。

【讨论】：

我注意到它也是字典，用设置名称作为键和值作为值（作为对象键入，但那会打开另一罐蠕虫）。感谢您的意见。

【解决方案3】：

使用列名来区分设置通常是一个糟糕的主意。您正在处理的实体是 SETTING，它具有 NAME 和 VALUE 属性。如果您需要在不同的上下文中使用相同的名称，请使 SETTING 分层，即除根以外的每个设置都有一个父级。然后，您的客户可以将根作为其父级，并且每个客户下的路径对于每个设置都是相同的。如果需要，您可以为其他数据类型使用不同的列。

【讨论】：