Sql 系统设置的表格设计，最佳型号

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

ID|IsAdmin|ImagePath
------------------------------
12 | 1 | \path\to\images
34 | 0 | \path\to\images

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

新桌子的设计方案。建议有一列用于设置名称，另一列用于设置。
ID |设置名称|设置值
----------------------------
12 | IsAdmin | 1
12 | ImagePath | \path\to\images
34 | IsAdmin | 0
34 | ImagePath | \path\to\images

他们的观点是，添加一个新设置就像向行中添加一个简单的insert语句一样简单，不需要添加列

---

但是第二个设计有点不对劲，看起来很糟糕，但我想不出任何反对的理由。我错了吗？

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

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

---

使用列名来区分设置通常是一个糟糕的想法。您正在处理的实体是设置，它具有属性名称和值。如果需要在不同的上下文中使用相同的名称，请将设置分层，即除根之外的每个设置都有一个父级。然后，您的客户可以将根目录作为其父目录，并且每个客户下的路径对于每个设置都是相同的。如果需要，可以对其他数据类型使用不同的列。
这是“”模式的变体（和）

---

它有一些优点和更多缺点，并且几乎可以保证以眼泪结束。
我认为在设置中使用EAV是可以的。围绕EAV设计完整的数据库是一个完全不同的故事，而不是OP所要求的。但我看不出文档数据库与您的观点有多么根本不同，我也看不出为什么使用它们也会以眼泪告终。@Johannes Rudolph:对于一个简单的系统设置表，那么是的。就像web.config中的appsettings一样。但是，与web.config一样，您使用专用部分进行更复杂的设置：不展开appsettings。最终，情况会变得更糟，因为有人会认为“多么好的主意”。说到这里，我已经用过了，但是你必须小心……感谢你的提醒，这是一个（粗略的）EAV版本，在链接和谷歌之间，我应该得到一些东西。引用完整性似乎存在一些问题。例如创建一个设置DefaultReportID，10当在1到9的报告表中存在时。我注意到它也是字典，它可能最终更好地包装在一个哈希中，设置名称作为键，值作为值（作为对象键入，但这将打开另一个蠕虫罐头）。谢谢你的意见。