将类存储为 sql 中的设置项是个好主意吗？答案

【问题标题】：Is it a good idea to store classes as settings items in sql?将类存储为 sql 中的设置项是个好主意吗？
【发布时间】：2017-02-04 18:34:35
【问题描述】：

我正在用 c# 做这个项目，在设计数据库时，我使用的规则是每个类基本上都是 sql 表（至少是必须持久化的类）。

由于某些类纯粹用于定义业务设置，而且这些类相当扁平，所以我很好奇做这样的事情是否有意义..

改造业务层类

class Contact
{
public string Name {get;set;}
public string PhoneNumber {get;set;}
public bool AcceptsTextMessages {get;set;}
public bool AllowedHoursForTextMessagesStart {get;set;}
public bool AllowedHoursForTextMessagesEnd {get;set;}
public List<DayOfWeek> SendMessagesOnlyOnWorkdays {get;set;}
}

到一个看起来像的数据层类（并将其保存在 sql 中）

public Settings
{
public ID {get;set}
public Name {get;set}
public Value {get;set;}
}

现实生活中的数据

ID   Name                                Value
1    Name                                John Doe
2    PhoneNumber                         01234657
3    ExceptsTextMessages                 true
4    AllowedHoursForTextMessagesStart    0
5    AllowedHoursForTextMessagesEnd      24
6    SendMessagesOnlyOnDays              1,2,3,4,5

这样做的主要原因是有一个设置表而不是像类一样多的表，可能更容易修改类，更容易在类之间操作属性（以防业务逻辑需要从一个类中移动一个属性给另一个）

【问题讨论】：

考虑到不同的用户可能有不同的设置，第一种方法可能更容易实现。当表的列太多或列本身因实体而异时，您真的只想使用第二种方法（正式称为实体属性值，EAV）。

标签： c# sql database database-design

【解决方案1】：

将您的对象分解为 ID 和属性值对是有时非常有用的技术之一。 EAV 数据的管理比具有单个列的平面表要复杂得多，因此不能轻易实现。

鉴于您发布的内容，我可能不会。您拥有的所有领域似乎都与成为联系人可靠相关，并且不太可能需要在生产中动态更改（因为一个人开始或停止接受短信，而不是上升到短信在认识论上无关的存在平面）。

即使将某些字段表示为成对是有意义的，我也只会对这些字段执行此操作：保留一个带有主键和基本数据的用户表，然后将其余部分放在一个带有外来键的 EAV 表中与用户的关键关系。

【讨论】：