灵活的形式和支持的数据库结构
我的任务是创建一个应用程序，允许管理员更改用户输入表单的内容（即添加任意字段） - 其内容存储在数据库中。想想 Modx/Wordpress/Expression Engine 模板变量。
我一直在研究的方法是实现规范一致的具体表（即用户配置文件、用户内容等）和一些通用字段数据表（即文本、布尔值）来存储非特定值。表单（和模型字段）将通过首先查询表并检索相关列来生成 - 尽管我还没有考虑如何设置验证。
我已经研究过这个问题，它似乎表明了一种 EAV 类型的方法 - 从我的简短研究来看 - 看起来它可能是一个比其灵活性带来的好处更大的负担。
然而，我在这里阅读了几篇文章，这些文章表明这是一条危险的路线：
，我将不胜感激。
有意见
如果有人对SWK
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.
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'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:
How to design a generic database whose layout may change over time?
I'd appreciate some advice on this matter if anyone has some to give
regards
SWK
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
几年前我创建了一个非常大的 EVA 数据库（PHP w/ PostgreSQL）。结果很棒，但这是一个大项目（$$$）。所有表单都是完全动态的，具有表单/字段版本控制、发布工作流程、匹配动态报告等。EVA
基础知识非常简单。输入数据并不是困难的部分。但是表单版本控制和报告......您可能需要花费数年时间才能做到正确。
如果我今天再次这样做，我会使用一种较新的 NoSQL 解决方案进行研究（http:// en.wikipedia.org/wiki/NoSQL#Document_store）。我想要创建一个可以传递给表单生成器的 DTO 样式类。 “修改”表单，实际上就是修改DTO。然后我会将 DTO 持久保存到文档/对象数据库中。
此外，当您构建 alpha 解决方案时，请考虑如何解决包含版本控制和报告需求的测试用例。
这是我的意思的一个例子：一个简单的“提问表格”。
现在，您需要生成一份报告（csv）。事情变得棘手。你怎么做？
我们通过引用以前版本的字段级版本控制解决了这个问题。另外，报告系统要求最终用户在运行之前组装报告数据源的定义。 （将报告字段绑定到数据字段等）。
但是，对于文档数据库，我想您可以采取不同的方式。我相信像 CouchDB（其他？）这样的新数据库具有内置的机制来处理这些问题。
祝你好运！！
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 basics are easy enough. Getting data in is not the hard part. But form versioning and reporting....you can spend years getting it right.
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.
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".
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).
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.
Good luck!!
在我的上一个网络应用程序中开发用户配置文件时，我选择了键/值表方法。这是我的数据库设计的样子：
与配置文件表链接的用户表（用户有许多配置文件）。
这样用户就可以将任何附加字段添加到他的个人资料中。例如：
等等
..
When developing user profiles in my last webapp, I've chosen Key/Value table approach. Here's how my DB design looks:
Users table linked with Profiles table (User HasMany Profile).
This way user can add any additional field to his profile. For example:
and
and so on..
根据您的需求，甚至可能不值得将表单字段提升到“数据库字段”级别。您可以改为在（本质上是）动态 blob 中序列化这些字段并将其存储在数据库中。如果您有人需要在您的应用程序之外查询这些动态字段（即数据库设计是具有集成系统的更大公共合同的一部分），但如果您只是使用该应用程序来保存，则不建议这样做这些动态字段或者如果字段内的任何聚合/搜索功能都很小，那么我会考虑它（特别是现在考虑到 CPU 功能）。我已经多次使用该模式，并且到目前为止，我从未需要重构。 （但是，我可以理解您可能需要的情况）。
Depending on your needs, it might not be worth even raising the form fields to the "DB fields" level. You could instead serialize these fields in (what is essentially a) dynamic blob and store it in the DB. This is NOT recommended if you have folks who need to query these dynamic fields outside of your app (i.e., the DB design is part of a larger public contract with integrated systems), but if you're just using the app to simply to persist these dynamic fields or if any aggregation/search capabilities within the fields are minor, then I would consider it (esp given CPU capabilities these days). I have used the pattern many times and I have - thus far - never had to refactor. (however, I can understand a case where you might need to).