Database 仅仅是一个存储，我们掌握了应用程序中所有的领域复杂性

例如，我们还让客户决定哪个属性是表单标题，因此如果

firstname

是表单标题，他们会将一个跨整个应用程序的内存参数设置为类似

Params.InMemory.TitleAttributeId=

---

我希望这能让您对类似场景的生产impl有一些了解。

这实际上更多的是一个评论，而不是一个答案，但我需要更多的空间来进行评论，所以这里是：

我认为您的UserConfiguration表方法很好，建议只对设计的“类型”和“值”部分进行更多的抽象：

• 因为应用程序需要验证用户输入，所以每个“类型”概念都有一个相关的评估逻辑。显然，您可以将这些内容提取到数据中的次数越多，代码就越容易保持小型化。枚举列表是一个很好的开始，但是如果您的“验证器”逻辑可以扩展到处理文本字符串和布尔逻辑表达式的模式匹配（例如，描述/强制执行输入值的约束），那么您可以用（相对）简单的“原子”来表示应用程序可能需要处理的几乎任何“类型”的输入您可以自然地映射到DB表

• 当存储用户指定的值时，您可以存储“原始”数据（例如JSON）和关联“类型”的外键，也可以添加一个查找/缓存系统，为系统遇到的每个新值分配一个整数（“新奇性”可以通过检查“原始”数据的散列进行检查，例如）。如果您希望有大量的数据重复，那么后一种方法显然可以更好地扩展（对于多选菜单，您当然会这样做）

---

如果这是一个离题的话题，那么你就不是一个真正的程序员。你看过这样的节目吗：？这似乎是一个相当全面的主题。@Simon Thx，还没有找到那个主题。

CREATE TABLE `attribute_value` ( -- enumerations go in this table
    `attribute` varchar(30), 
    `value` varchar(30), 
    PRIMARY KEY (`attribute`, `value`)
);

CREATE TABLE `eav` ( -- now the values of attributes are restricted
    `entityid` int, 
    `attribute` varchar(30), 
    `value` varchar(30), 
    PRIMARY KEY (`entityid`, `attribute`), 
    FOREIGN KEY (`attribute`, `value`) REFERENCES `attribute_value`(`attribute`, `value`)
);

Form
 Id

Attribute (or Field)
 Name
 Type (enum) Text, List, Dates, Formulas etc
 Hidden (bool)
 Mandatory
 DefaultValue
 Options (for lists)
 Readonly
 Mask (for SSN etc)
 Length (for text fields)
 Order

Metadata
 FormId
 AttributeId
 Text (the value for everything but dates)
 Date (the value for dates)

AttributeIncrementFormula
 AtributeId
 Counter
 Token

var form = formRepository.GetById(1);
form.Metadata["firstname"].Value