允许用户构建简单 Web 表单的数据库架构
想象一个 Web 服务,它允许用户构建几种不同类型的定制 Web 表单,然后使用不同的值填充每个表单的多个实例。
例如,制作一个名为“我看过的电影”的表单,其中包含“类型”、“年份”、“导演”等字段,另一个表单名为“我看过的书籍”,其中包含“作者”、“页数”等字段等等,然后在我的个人资料中注册很多电影和书籍。
我试图弄清楚应该如何组织该服务的数据库以获得最大的多功能性:
我想到的最明显的方法是为创建的每个新表单创建一个单独的表,但这看起来可能编程缓慢且乏味。
另一种方法是限制用户可以插入的字段数量,并创建一个表来保存所有“表单”并具有“Custom_value_1”、“Custom_value_2”等列(我必须存储 另一种方法是限制用户可以插入的字段
还没想到:)
Picture a web service that lets a user construct several different kinds of custom-made web forms and then fills multiple instances of each form with different values.
For example, make a form named "movies I have watched" with fields such as "genre", "year" "director" etc. and another form "books that I have read" with fields such as "author", "pages" etc. and then register a lot of movies and books in my profile.
I am trying to figure out how the DB for this service should be organized for maximum versatility:
The most obvious way that I thought of is to have a separate table for every new form that is created, but that looks like it might be slow, and tedious to program.
Another approach is to limit the number of fields that a user can insert, and create one table that holds all "forms" and has columns such as "Custom_value_1", "Custom_value_2", etc. (I will have to store the label and data type of each value in another table).
Haven't thought of it yet :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您正在考虑构建特定于领域的关系数据库和键值模型系统之间的区别。您可以查找这些术语以了解有关它们的更多信息。
键值系统更加灵活,但难以编程。关系模型要求您正确地对您可能想要放入数据库中的每种“事物”进行建模,这不太灵活,但更容易编程(因为您几乎可以通过内省数据模型来构建表单) 。
在这种情况下,听起来这两种解决方案都不是最适合您的解决方案。我会研究一些更灵活的文档类型存储。特别是,这听起来对于 XML 或面向 XML 的数据库来说可能是一项不错的工作。
You are considering the difference between building a domain-specific relational database and a key-value model system. You can look those terms up to learn more about them.
The key-value system is more flexible, but difficult to program. The relational model requires you to correctly model each kind of "thing" that you might want to put in the database, which is less flexible but much, much easier to program (since you can pretty much build the forms from introspecting the data model).
In this case, it sounds like neither is really the best solution for you. I'd look into some more flexible document type storage. In particular, this sounds like it might be a good job for XML or an XML oriented database.