问候堆垛机,
我正在尝试为应用程序提供最佳数据库架构,以便用户创建调查并将其呈现给公众.有大量"标准"人口统计字段,大多数调查(但不是全部)将包括,如名字,姓氏等.当然,用户可以创建无限数量的"自定义"问题.
我想到的第一件事是这样的:
Survey ID SurveyName SurveyQuestions SurveyID Question Responses SurveyID SubmitTime ResponseAnswers SurveyID Question Answer
但每次我想查询数据时,这都会很糟糕.它似乎危险地接近内部平台效应
一个改进是在响应表中包含尽可能多的字段:
Responses SurveyID SubmitTime FirstName LastName Birthdate [...]
那么至少对来自这些公共列的数据的查询是直截了当的,并且我可以查询,例如,每个回答任何调查的人的平均年龄,他们给出了他们的出生日期.
但似乎这会使代码复杂化一些.现在,要查看调查中询问的问题,我必须检查哪些常见响应字段已启用(使用,我猜测,调查中的位域)以及SurveyQuestions表中的内容.而且我不得不担心特殊情况,比如有人试图创建一个"自定义"问题,该问题会在"响应"表中复制"常见"问题.
这是我能做的最好的吗?我错过了什么吗?
您的第一个架构是两者中更好的选择.此时,您不必担心性能问题.担心制作一个好的,灵活的,可扩展的设计.以后可以使用各种技巧来缓存数据并加快查询速度.使用灵活性较低的数据库模式来解决甚至无法实现的性能问题是一个糟糕的决定.
此外,许多(可能是大多数)调查结果只能由少数人(活动组织者,管理员等)定期查看,因此您不会经常查询数据库中的所有结果.即使你是,表现也会很好.无论如何,你可能会以某种方式对结果进行分页.
第一个模式更灵活.默认情况下,您可以包含姓名和地址等问题,但对于匿名调查,您可能根本无法创建它们.如果调查创建者只想查看每个人对五百个问题的答案,那就是一个非常简单的SQL查询.您可以设置级联删除,以便在删除调查时自动删除回复和问题.使用此架构也可以更轻松地生成统计信息.
这是您提供的架构的略微修改版本.我假设您可以找出哪些数据类型去哪里:-)
surveys survey_id (index) title questions question_id (index, auto increment) survey_id (link to surveys->survey_id) question responses response_id (index, auto increment) survey_id (link to surveys->survey_id) submit_time answers answer_id (index, auto increment) question_id (link to questions-question_id) answer