我试图找出如何确定数据库结构的最佳平衡点。我希望能够存储来自不同人提交的多种不同表单的信息，有时是多次（例如每年更新）。我在每个表单都有一个不同的表，或者表单和元素定义以及元素值表的组合之间停留。
示例A：有三种类型的表单具有不同的信息，因此有四个表，[FormA]，[FormB]和[FormC]，每个表都有与其各自表单相关联的数据，所有表格均为[客户] ]
示例B：相同的三种形式，但这次有五种不同的表格。 [FormDescriptions]定义表单名称，类型等，并有三个条目，每个表单一个。 [表格] FK到[客户]和[FormDescriptions]，并将这些与提交日期结合使用，以区分各个提交。 [FormElements]定义了三种形式的所有元素，FormDescriptions上有一个FK和一个唯一的elementID。 [ElementValues] FK到[FormElements]和[Forms]并将所选元素的值存储在所选表单上。
我的问题是，这些方法中的一种本质上比另一种更好，如果不是，哪种情况比另一种更好？为什么或者为什么不想要包括的内容值得赞赏。
答案 0 :(得分：3)
＆＃34;我的问题是，这些方法中的一种本质上比另一种更好，如果不是，哪种情况比另一种更好？为什么或者为什么不想要包括的内容值得赞赏。＆＃34;
您的选项二是（您的个性化变体）EAV反模式。如果你使用它，你希望（现在或以后）系统做任何事情＆＃34;智能＆＃34;有了这些数据，你会发现自己陷入了严重的困境。和基本一样严格的数据验证以捕获数据输入错误＆＃34;已经被认定为＆＃34;智能＆＃34;。因此，只有在您能够合理地预期系统将仅用于仅仅存储数据时才使用它，并且不可能有任何请求以智能方式开始处理/操纵数据＆＃34;。
如果你曾经遇到要求开始做＆＃34;智能＆＃34;有了EAV数据库的东西，你会发现无论你认为通过使用超级通用信息模型获得的开发时间，你都会失去更多时间来编码所有＆＃34;智能＆＃ 34;需要的东西，即恢复您拒绝在数据库中反映的代码中的数据结构。
用Google搜索＆＃34; EAV反模式＆＃34; （尝试找到Bill Karwin的书）应该为你提供足够的信息，说明为什么不这样做。答案 1 :(得分：1)
这里考虑了两个因素
如果您的系统需要在将来频繁添加更多表单，方法2会更好。您不必添加其他表或列。您的表单是数据驱动的。它将为生成表单和保存为键值对增加很少的开销。
另一方面，如果您的系统不需要对表单进行多次更改，则第一种方法可以正常工作。
在提交表单后，还要考虑使用数据。你打算运行分析，报告这些数据吗？这些报告是否特定于表格？这将有利于方法1.