我是创建数据库的新手,这是我还没有做过的最复杂的数据库,我想确保我遵循设计中的最佳实践。 (这只是一个私人项目,我正在努力学习)
基本上我会存储可能有多个问题的问卷。如果已经创建了问题,可以在多个调查问卷上重复使用问题,因此我有一个智能搜索类型的界面来检查数据库。
然后,我对每个与问卷调查问题相关的问题以及在约会时回答问题的用户提供答案。
我还有多种问题类型:select,text,text_area,number,date,radio。
对于选择类型,我会有一个选择表,表明选择可用的选项。
用户表会在使用问卷时链接到答案。
当问题依赖于另一个时,我也会有问卷依赖关系:你吸烟吗?如果是 - >你抽多少钱?
我不太确定的事情是使用联结表的多对多关系,并自我引用联结表中的问题以形成依赖关系。 这会被认为是一个正确的设计,如果不是我做错了什么?
答案 0 :(得分:3)
在关系模式中,您将通过自联接外键表示问题依赖性;你不需要回到联络表,因为这两个问题之间的关系独立于每个问题与调查问卷的关系。
但是,正如您可能已经注意到的那样,在关系模式中表示一组分支问题不仅有点尴尬。如果调查问卷是您存储的大部分内容,您可能需要查看MongoDB(或使用Postgres中的JSONB字段)等替代方案,这样您就可以将调查问卷表示为包含嵌套问题的文档。单个用户对问卷的回复包括第二(类型)文档;所有收集的问卷调查结果都可以通过用户或问卷调查轻松搜索,您可以使用聚合工具切片和挖掘个别问题答案。
将调查问卷和问题作为文件处理也可以为您提供一些更灵活的工具来表示依赖性:而不是“吸烟”之间的硬链接?"和"多少?",您可以将验证器应用于conditions
对象(如果存在),并且只询问是否满足任何条件的问题:
[..., {
"name": "smoker",
"text": "Do you smoke?",
"values": [true, false]
}, {
"name": "how-much",
"text": "How much do you smoke?",
"conditions": {
"smoker": true
},
"values": ["Socially", "< 1 pack/day", "1 pack/day", "2 packs/day", ...]
}, ...]