这是Table design about sets of data collection elements的后续问题，因为我仍在尝试设计。
我想要做的是能够预先定义哪些研究/协议对需要作为数据集合显示，就像待办事项列表或检查表一样，可以在患者的门诊就诊时进行跟踪。附件是我到目前为止在每个表中可能的示例但我从未实现超类型/子类型关系所以我不确定我是否在正确的轨道上。它是否过度正常化？或者我是否应该打扰使用超类型/子类型？
任何想法/反馈都会有所帮助。
编辑
@YoungBob首先感谢您的投入。 FormId（PK）也是DataCollectionId的外键，所以我可以通过DataCollection.DatacollectionId = Form.FormId查询具有相同ID的表，以获得两个级别属性，不是吗？
我不会提供动态创建这些表单的界面，这就是为什么我不想包含部分或问题类型但我喜欢包含版本控制的想法。
正如您所提到的，我将使用测试数据加载它以查看性能是否应该对任何表进行反规范化。
自从我发布问题以来，我已按照您的建议添加了DataCollectionIntervals的链接 - 它看起来好多了吗？
答案 0 :(得分：0)
架构设计对我来说很合适，至少基于您在此帖和上一篇文章中提供的信息。最佳实践是从标准化设计开始，然后在您认为需要查询优化的位置进行反规范化。我猜测数据库不会很大或交易率很高，因此性能不应成为问题，所以我会坚持使用标准化设计。根据经验，如果您需要编写连接超过4个表的查询（至少在sql server中），则非规范化可能是值得的，但我无法真正看到这种模式设计发生的情况。
正如您在问题中所建议的那样，Form和Sample表可以通过在DataCollection表中包含两者的属性来成为非规范化的候选者，但这取决于Form和Sample有多少其他属性以及两者共有多少。
我要给的一个提示是考虑给Form表一个短字符串的主键，假设你有相当标准的表单，我发现在浏览表时会让生活变得更容易（例如有点像HMRC表格P45， P60等或机场代码LHR，JFK等）因为您不必继续与其他表连接以记住特定的int ID所指的形式。 CHAR（3）字段也比INT使用更少的存储空间。这可能适用于其他表，如DataCollectionType。但这可能是个人偏好的问题。
根据我们在上一篇文章中的讨论，我们谈到的DataFrequency表可能应该是DataCollection表的多个-1链接。也许DataCollectionIntervals可能是一个更好的名称。
在设计中要考虑的另一件事是，一些经常访问的表是否有利于形成垂直分割。通过这个我的意思是，如果表有宽行，即很多属性或存储饥饿属性，如VARCHAR（MAX）不经常访问的属性可以分成一个单独的表与1-1链接，这可以显着提高涉及此表的查询性能。但正如我所说，我并不认为性能是您计划的数据库大小的问题，并假设您将使用类似SQL Server的东西。
最后一件事......表单的结构可能比目前指出的模式稍微复杂一些，例如，表单通常被分成几个部分，所需的问题类型可能非常复杂，例如：多项选择，文本，分支，条件。表单也可以存在于不同的版本中（使用Active标志来标识Forms表中当前活动的版本）。我已经看过自己使用queXML来设计XML格式的调查问卷，但我认为它对我所需要的东西有点过分，所以我决定使用我自己的一个更简单的XML模式，可以导入到数据库中。
