将数据库中的应用设置/首选项保留为JSON？

Question

这是我倾向于构建的Web应用程序中不断出现的需求之一。我们谈论的是需要坚持这样的结构：

public interface IAppSettings
{
    string AppName { get; set; }
    string SupportEmailAddress { get; set; }
    bool IsEmailEnabled { get; set; }
    // etc.
}

我经常从简单地使用web.config中的内置AppSettings开始，但随后它们通常会变成持久存储在数据库中（出于各种原因）。在这种情况下，我通常会做两件事之一：

1。将设置存储为两列“首选项”表中的键值对

...其中key和value列都是简单的nvarchar字符串。这类似于在web.config中使用AppSettings，而是存储在数据库中。

CREATE TABLE [dbo].[Preferences] 
(
    [Key] [nvarchar(50)] NOT NULL,
    [value] [nvarchar](200) NOT NULL
)

或者...

2。将设置作为单行存储在多列“首选项”表

中

...其中每列代表具有特定数据类型的命名首选项。好处是我可以更准确地捕获数据类型（字符串与布尔值等），但缺点是添加属性需要进行架构更改，而不是像方法＃1那样添加更多的键值行。

CREATE TABLE [dbo].[Preferences] 
(
    [AppName] [nvarchar(50)] NOT NULL,
    [SupportEmailAddress] [nvarchar](250) NOT NULL,
    [IsEmailEnabled] [bit] NOT NULL
)

我并不完全喜欢这两种方法中的任何一种，所以这次我正在考虑另一种方法：

3。将首选项存储为单个列“首选项”表

中的序列化JSON字符串

CREATE TABLE [dbo].[Preferences] 
(
    [PreferenceValues] [nvarchar(max)] NOT NULL
)

想到的潜在好处是：

• 该结构很容易反序列化为IAppSettings对象并在应用程序内部使用。
• JSON将允许更复杂/嵌套的结构（复杂的子类型，数组等）。例如，“管理员电子邮件地址”或类似的数组。
• 添加/删除属性只是更新整个对象并将其覆盖为数据库中新的序列化JSON字符串。

潜在的缺点：

• 使用单行，单列表似乎滥用了关系数据库。但是，如果需要在SQL中持久保存数据，并且连接和其他“关系”事物不需要该数据，那么我不确定我是否会看到它的危害。它真的比上面的＃1更差吗？
• 如果IAppSettings定义发生更改，数据可能会处于奇怪的状态，并且持久化的JSON数据已过期，现在无法再进行正确的反序列化。但是有一些方法可以在NoSQL世界中管理JSON文档版本，所以我只需要采用一些方法，我认为。

对此有何想法？以前有人走过这条道路并有任何分享的智慧吗？