关系设计:列属性
我有一个系统,允许人们从下拉框中选择他们想要填写的表单类型。由此,将显示该特定表单的其余字段,用户填写它们并提交条目。
表单表:
| form_id | age_enabled | profession_enabled | salary_enabled | name_enabled |
它描述了表单的元数据,以便系统知道如何绘制它。因此,如果表单应包含要为此列填写的字段,则每个 _enabled 列都是布尔值 true。
条目表:
| entry_id | form_id | age | profession | salary | name | country |
存储提交的表单。其中年龄、职业等存储表单中填写的实际值(如果表单中不存在则为空)
用户可以动态添加新表单到系统。
现在的主要问题是:我想为用户添加设计新表单的功能,使其能够包含属性的可能值列表(例如,职业是包含 20 个职业的下拉列表,而不仅仅是一个文本框)填写表格时)。我不能简单地存储每列的可能值的全局列表,因为每个表单都有不同的值列表可供选择。
我能想到的唯一解决方案是在表单表中包含另一组列,例如 professional_values,然后以字符分隔格式存储值。我担心有一天某一列可能会有大量可能的值,并且该列将失去控制。
请注意,如有必要,可以稍后将新列添加到 Form(依次添加 Entry),但 90% 的表单具有相同的基本列集,因此我认为这种设计比 EAV 设计更好。想法?
我从未见过这样一个系统(作为一个整体)的关系设计,而且我似乎无法找到一个合适的方法来做到这一点。
I have a system that allows a person to select a form type that they want to fill out from a drop down box. From this, the rest of the fields for that particular form are shown, the user fills them out, and submits the entry.
Form Table:
| form_id | age_enabled | profession_enabled | salary_enabled | name_enabled |
This describes the metadata of a form so the system will know how to draw it. So each _enabled column is a boolean true if the form should include a field to be filled out for this column.
Entry Table:
| entry_id | form_id | age | profession | salary | name | country |
This stores a submitted form. Where age, profession, etc stores the actual value filled out in the form (or null if it didn't exist in the form)
Users can add new forms to the system on the fly.
Now the main question: I would like to add the ability for a user designing a new form to be able to include a list of possible values for an attribute (e.g. profession is a drop down list of say 20 professions instead of just a text box when filling out the form). I can't simply store a global list of possible values for each column because each form will have a different list of values to pick from.
The only solution I can come up with is to include another set of columns in Form table like profession_values and then store the values in a character delimited format. I am concerned that a column may one day have a large number of possible values and this column will get out of control.
Note that new columns can be added later to Form if necessary (and thus Entry in turn), but 90% of forms have the same base set of columns, so I think this design is better than an EAV design. Thoughts?
I have never seen a relational design for such a system (as a whole) and I can't seem to figure out a decent way to do this.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
创建一个新表来包含值组:
例如:
因此,组 1 包含下拉选择器的三个可能值。然后,您的表单可以引用特定列使用的组。
另请注意,您应该通过行而不是列将字段添加到表单中。即,当您添加新表单时,您的应用程序不应该调整架构,它应该只创建新行。因此,将每个字段设为自己的行:
Create a new table to contain groups of values:
For example:
So, group 1 contains three possible values for your drop-down selector. Then, your form table can reference what group a particular column uses.
Note also that you should add fields to a form via rows, not columns. I.e., your app shouldn't be adjusting the schema when you add new forms, it should only create new rows. So, make each field its own row:
我认为你完全从错误的地方开始。
您是否要继续向该表中添加您可以拥有的每个字段?一般来说,这个列表可能是无穷无尽的。
如果所有字段都在此表的列中,您的应用程序代码将如何显示表单?
像这样的表单怎么样:
然后是另一个表,formAttributes,表单上每个条目一行:
然后是第三个表 forAttributeValidValues,每个属性有效值一行:
这可能看起来需要更多工作,但实际上并非如此t。想一想向表单添加或删除新属性或值是多么容易。还要考虑您的应用程序将如何呈现表单:
接下来的困境将变成如何存储表单结果。理想情况下,您可以将它们存储在一个表中,每个表单元素 1 行,如下所示:
如果您一次只处理一个表单,那么此模型将运行良好。如果您想对大量表单进行聚合,那么生成的查询会变得更加困难,但是这是报告,它可以在与在线表单输入不同的进程中运行。您可以开始考虑通过旋转查询将行转换为列或物化视图以将相同类型的表单组合在一起等的事情。
I think you are starting from the wrong place entirely.
Are you just going to keep adding to this table for every single for field you can ever have? Generically the list could be endless.
How will your application code display a form if all the fields are in columns in this table?
What about a form table like this:
Then another table, formAttributes with one row per entry on the form:
Then a third table forAttributeValidValues with one row per attribute valid value:
This may seem like more work to begin with, but it really isn't. THink about how easy it is to add or remove new attribute or value to a form. Also think about how your application will render the form:
The dilema will then become how to store the form results. Ideally you would store them with 1 row per form element in a table that is something like:
If you only ever work on one form at a time, then this model will work well. If you want to do aggregations over lots of forms, then the resulting queries become more difficult, however that is reporting, which can run in a different process to the online form entry. You can start to think of things that pivot queries to transform the rows in into columns or materialized view to pull together forms of the same type etc.