将类作为设置项存储在sql中是一个好主意吗？

Question

I am doing this project in c# and when designing a database, i am using a rule that each class is basically sql table (at least the class that has to be persisted).

Since some classes are purely used to define business settings and the classes are rather flat, I am curios does it make any sense to do something like this..

Transform business layer class

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;}
}

to a data layer class that look something like (and persist it in sql)

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

with real life data

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

The primary reason for this is to have one settings table instead of having as many tables as classes, possibly easier class modification, easier manipulation of properties between classes (in case there is a business logic need to move one property from one class to another)

Answer 1

Decomposing your objects into IDs and attribute-value pairs is one of those techniques that's sometimes extremely useful. EAV data is much more complicated to manage than a flat table with individual columns, so it's not something to implement lightly.

Given what you've posted, I probably wouldn't. All the fields you have seem reliably relevant to being-a-contact and unlikely to require changing around dynamically in production (since one starts or stops accepting text messages, rather than ascending to a plane of existence where text messages are epistemologically irrelevant).

Even if it made sense to represent certain fields as pairs, I'd only do it for those fields: keep a users table with a primary key and the essential data, then put the rest off in an EAV table with a foreign key relationship to users.