SystemSettings的表设计，最佳模型

Question

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

ID | IsAdmin | ImagePath的
------------------------------
12 | 1 | \路径\为\图像
34 | 0 | \路径\到\ IMAGES

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

新表设计方案。建议是设置一个用于设置名称的列和另一个用于设置的列 ID | SettingName | SettingValue
----------------------------
12 | IsAdmin | 1
12 |的ImagePath | \路径\为\图像
34 | IsAdmin | 0
34 |的ImagePath | \路径\到\ IMAGES

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

但是对于第二种设计感觉不对，它看起来很糟糕，但我无法提出反对它的任何论据。我错了吗？

Answer 1

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

它有一些优点和更多的缺点，它几乎可以保证以泪水结束。

Answer 2

第二种方法实际上类似于字典。我发现这是我正在处理的应用程序的一个更方便的选择，原因是你提到的。这种方法有一些注意事项，所以你需要小心它们：

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

Answer 3

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