在我参与过的多个Web应用程序项目中，客户要求能够创建自己的表单。问题在于如何存储其表单定义，然后如何将用户输入的值存储到这些自定义表单中。

我已经看到它做了两种方式：

• 假设客户端仅定义了多少个字段以及与这些字段相关联的标签；我们可以得出一个涉及四个表的解决方案。 FormDefinition，FormFieldDefinition，FormInstances，FormFieldValues。客户端对FormDefinition和FormFieldDefinition进行了更改，Web应用程序使用该信息来呈现HTML Web表单，网站访问者(最终用户)将在HTML Web表单上提交表单，其中FormInstances中的新行创建，并将值保存在" FormFieldValues"表中。

Rows in FormDefinition defines the form, i.e. form definition ID = 2, form title = 'Car Registration Form'. Rows in FormFieldDefinition defines fields of a form in FormDefinition, i.e. field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'. Rows in FormInstance is an instance of each form filled out by a user, i.e. definition id = 2, date_entered = '2008-09-24'. And rows in FormFieldValues are entries by the user, i.e. field definition = 7, value = 'Tiburon'.

不幸的是，这意味着" FormFieldValues"中的value列必须是客户可能在网络表单中指定的最大大小的char类型...并且当表单定义更改时，对旧数据的管理变得很困难。但是用户条目是可查询的(我写了一个快速查询，列出了具有表单ID的用户条目，这类似于另一个关键问题)。

• 使用四个表的替代方法是将表单定义和用户的表单条目序列化为XML(或者YAML或者类似名称)并将其存储为文本。好处是表单在数据库中是人类可读的。缺点是解析XML会增加应用程序开销，并且从SQL的角度来看，数据库的可查询性将大大降低。

我真正的问题是，这个数据库模型叫什么？ (所以我可以用谷歌搜索这个问题。)但是我会回答一个答案：哪个是更好的实现，或者那里有更好的(或者同样好的)实现？

解决方案

what is this database model called?

不知道该如何称呼它，但这与动态生成调查所使用的过程相同。如果我们寻找生成调查应用程序的任何来源，我们会发现相同的常规数据库模式以及相似的方法。

还可以查看表单构建器网站，例如http://wufoo.com/或者http://frevvo.com/，以获取UI提示(如果要使其基于Web)。

第三个选项是在其中创建表并在需要时添加列。这取决于创建的表格数量，但是数据库可以轻松处理很多表。因此，如果用户要添加"汽车登记表"表格，则可以添加表" CarRegistrationForm"。对于他们想要在表单上的每个字段，我们可以让他们在一些基本类型之间进行选择，例如日期，整数和文本。并选择文本时，他们必须从选择列表，它给你的信息，如果该领域应该是一个varchar或者CLOB输入的最大长度。

这在SQL Server上有效，我们可以在其中轻松地添加和删除列。对于DB2，这可能是个问题，因为未实现drop列。对于mysql我不确定。

我们仍然需要在两个单独的表中注册表单及其上的字段。

我们所描述的内容通常称为"实体-属性-值"，有时也称为"混合数据和元数据"。即，属性(字段)的名称存储为字符串(数据)。

这会导致一系列复杂的问题，例如确保每个表单实例都包含相同的字段集，或者确保填写必填字段(相当于常规表中的NOT NULL)。

我们问如何最好地使用关系数据库来做到这一点。在关系数据库中，应将元数据用于元数据。在这种情况下，这意味着为每个表单创建新表，并将列用于表单字段。因此，表单定义就是表元数据，而一个表单实例就是该表中的一行。如果我们支持带有多值答案的表单(例如复选框)，那么我们还需要依赖表。

这似乎很昂贵或者很难扩展。可能是真的。因此，关系数据库可能不是这项工作的最佳工具。我们提到了XML或者YAML的可能性；基本上可以定义的某种结构化文件格式。我们应该为每个客户的表单定义一个DTD，以便可以验证收集的每个表单。

编辑：如果我们确实需要在应用程序中使用EAV的灵活性，那很好，通常在某些情况下可以证明违反规则是合理的。只需了解它会花费的额外工作，并在开发计划中以及在扩展服务器以处理负载时计划它。另请参阅我关于StackOverflow上EAV的另一个答案。

我们可能需要实体关系模型

实际上，确实存在GUI工具可从此类模型以交互方式创建架构。