1

我想构建一个与wufoo非常类似的在线表单生成器,它允许用户创建和发布他们自己的Web表单。每次提交应保存到用户以后可以检索提交内容的数据库中。在SQL中存储用户定义数据的正确方法

由于这些形式将是动态的,即。用户可以完全控制表单字段的数量和类型,我试图想到一个坚实的数据库设计来存储这些信息。

我会有一个表字段类型,其中包含用户可用的每种类型的字段,即。文本框,emailfield等

将举行各形式的ID只能有一个基本形式表,网址等

然后我会,其中将包括裁判的基本形式和字段类型的表formfields,该表还包括自定义验证将在每个领域完成。

这种设计是否适合作为基础结构?我想,向应用程序添加新类型的字段会很容易,但我不知道潜在的缺点是什么,因为我离sql专家很远。

回答

1

在SQL

存储用户定义的数据,我认为你正在寻找Entity–attribute–value数据库模型,其中:

的基本思想是存储属性,及其相应的值, 作为单个表中的行。

通常情况下,表格至少有三列:实体,属性和 值。尽管如果只有一个相关实体,例如对于应用程序配置或选项设置,表 可以排除实体列 。

看到这个页面作为开始:

我重新标记您的问题与标签,在其中你可以浏览很多与你的案例相关的线索。

+0

非常感谢您的回答entity-attribute-value恰恰就是我正在寻找的模型。 – justinfay

+0

EAV被称为classis反模式... http://karwin.blogspot.com/2009/05/eav-fail.html您选择了错误的路径。 – Borys

+0

@Borys - 你说得对,但是OP正在寻找一种方法来完成对表单域数量和类型的完全控制。如何让用户能够使用规范化的数据库模型创建表单的字段和表单的类型,并且无法知道每个字段的属性?它是动态的,你不能分辨出每个表单的列。 –

0

正如Mahmoud Gamal所写,您描述的模型是“实体/属性/值”;正如Borys写道,这个模型存在许多已知的问题。

或者,您可以考虑将表单条目存储在“文档”中 - 例如, XML或JSON - 在关系模型中。

例如,你可能有沿的线表:

FORM_SUBMISSION 
-------------------- 
Submission_ID (pk) 
Client_ID (fk to clients table) 
Submission_date 
SubmissionDocument 

我使用的“客户”代表谁创建表单的用户;要检索给定客户端的所有提交内容,请在client_id上使用where子句。

该模型使得对表单提交运行SQL查询变得更加困难(尽管当超出非常简单的查询时,EAV也变得很难),但它极大地简化了持久性解决方案。

+0

谢谢你的答案Neville。 – justinfay

相关问题