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