灵活的形式和支持的数据库结构 [英] Flexible forms and supporting database structure
问题描述
我的任务是创建一个应用程序，允许管理员更改用户输入表单的内容（即添加任意字段） - 其内容存储在数据库中。认为Modx / Wordpress / Expression Engine模板变量。
I have been tasked with creating an application that allows administrators to alter the content of the user input form (i.e. add arbitrary fields) - the contents of which get stored in a database. Think Modx/Wordpress/Expression Engine template variables.
我一直在研究的方法是实现具体表格，其中规范是一致的（即用户配置文件，用户内容等）和一些通用字段数据表（即文本，boolean）来存储非特定值。表单（和模型字段）将通过首先查询表和检索相关列来生成 - 尽管我还没有想到如何设置验证。
The approach I've been looking at is implementing concrete tables where the specification is consistent (i.e. user profiles, user content etc) and some generic field data tables (i.e. text, boolean) to store non-specific values. Forms (and model fields) would be generated by first querying the tables and retrieving the relevant columns - although I've yet to think about how I would setup validation.
I我们看了这个问题，似乎表明了一种EAV类型的方法 - 从我的简短的研究来看，这种方法看起来可能比它灵活性带来的祝福更为重要。
I've taken a look at this problem, and it seems to be indicating an EAV type approach - which, from my brief research - looks like it could be a greater burden than the blessings it's flexibility would bring.
我已经阅读了几个帖子，但是，这表明这是一条危险的路线：
I've read a couple of posts here, however, which suggest this is a dangerous route:
如果有人给了一些这样的事情，我会感谢一些建议。
I'd appreciate some advice on this matter if anyone has some to give
SWK
推荐答案
我创建了一个非常大的EVA数据库几年前（PHP w / PostgreSQL）。事实证明是伟大的，但它是大项目（$$$）。所有表单都是完全动态的，具有表单/字段版本控制，发布工作流程，匹配动态报告等。
I created a very large EVA database years ago (PHP w/ PostgreSQL). It turned out great, but it was large project ($$$). All the forms were completely dynamic, with form/field versioning, publishing workflows, matching dynamic reporting, etc.
EVA基础很简单。获取数据不是很难的部分。但是形式的版本和报告....你可以花几年时间才能正确的。
EVA basics are easy enough. Getting data in is not the hard part. But form versioning and reporting....you can spend years getting it right.
如果我今天再做一次，我会研究使用一个较新的NoSQL解决方案（ http://en.wikipedia.org/wiki/NoSQL#Document_store ）。我想要创建一个可以传递给表单生成器的DTO样式类。 修改表单，实际上是修改DTO。然后我会坚持把DTO保存在一个文档/对象数据库中。
If I was doing it again today, I would research using one of the newer NoSQL solutions ( http://en.wikipedia.org/wiki/NoSQL#Document_store ). I'd thing about creating a DTO style class that could be passed to a form generator. "Modifying" the form, would actually be modifying the DTO. Then I would persist that DTO into a document/object database.
另外，在构建alpha解决方案时，想想如何解决包含版本控制和报告的测试用例需要。
Also, as you are building your alpha solution, think of how to solve test cases that encompass versioning and reporting needs.
这是一个例子，我的意思是：一个简单的提问表单。
Here is an example of what I mean: A simple "Ask Question form".
- 原始（版本1）：有第一个，最后一个问题
- 添加电子邮件字段（版本2）： ，问题
- 有人改变主意：（版本3）：第一，最后一个问题
<新的营销人员进来改变它：（版本4）：全名，电子邮件，问题
- Original (version 1): has First,Last,Question
- Add email field(Version 2): First,Last,Email,Question
- Somebody changes their mind about email: (version 3): First,Last,Question
- New marketing guy comes in and changes it: (version 4): Full Name,Email,Question
现在，您需要生成一个报告（csv）。事情变得棘手你如何做？
Now, you need to generate a report (csv). Things get tricky. How do you do it?
我们通过引用其以前的版本来解决了这个问题。此外，报告系统需要最终用户在运行之前汇编报表数据源的定义。 （绑定报告字段到数据字段等）。
We solved this problem with field level versioning with references to their previous versions. Plus the reporting system required the end user to assemble the definition of the report data sources before running. (binding report fields to data fields, etc).
然而，凭借这个文档数据库，我可以想象你可以做的不一样。我相信新的数据库就像CouchDB（其他人）有内置的机制来处理这些问题。
However with the document DB's I'd imagine you can do it differently. I believe the new DB's like CouchDB (others??) have mechanism built in for handling these issues.
祝你好运！
这篇关于灵活的形式和支持的数据库结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
