mysql - 最好将单个表用于当前和存档记录，还是一个用于存档，一个用于当前？

Question

我使用的应用程序之一是 Spring JPA 临床记录应用程序。它有两个表格来跟踪录取情况；“访问”和“录取”。Visits 是一个巨大的表格，其中包含 100,000 名患者的就诊记录。入院是一个“活动”表，仅保存当前入院患者的记录。随着患者出院，他们将从入院表格中删除。这里的想法是用户主要对当前的录取感兴趣，所以我们需要快速的当前录取搜索——因此需要更小的表格。但是，它确实增加了复杂性和开销，而在访问表上可能只是有一个“已接受”标志，并且当前允许的查询可以搜索访问，从而简化应用程序结构并可能提高性能。我在这里理解正常形式，并且跨两个表复制数据有点破坏了它。我只是想知道单个表是否是首选方法，或者当前的设计是否合适？我主要关心的是性能，并且在测试中没有显着差异（从用户的角度来看）。我不相信这个问题有任何公认的“模式” - 但可能有？

标签： mysqlspringpostgresqljpa

Answer 1

一行代表什么？大概不是“人”，而是某种行为（访问、入院、出院等）？

访问次数会是录取人数的几倍？

招生仅限于“目前占用床位的人”吗？还是包括以前出院的患者？

为了帮助解决上述问题，请考虑需要执行哪些查询。以及这些查询中需要哪些数据。

教科书将坚持使用一种“适当”的数据库布局形式。我倾向于实用主义。以下是一些将我推向单独表格的因素：

• 例如，visits中的行数比 中的行数大得多admissions。
• 两个表中都没有显示大量的列。
• 许多查询只需要查看一张表，而不需要查看另一张表。（UNION ALL可以在您需要两者的数据时使用。）
• “公共”数据可以从两者中归一化。（例如：关于 ' 的非医院信息person。注意： address等会随着时间而改变。）
• 需要不同的索引来优化不同的查询。
• 也许“入场”是“访问”的超集？也就是说，每个表中可能有一行用于单个事件。（cfJOIN或者也许LEFT JOIN。）

没有正确的答案。比赛中甚至可能没有明确的赢家。以一种方式实施它，但真诚的意图是在几个月内重新审视这个问题。

您提到较小的表更快 - 这取决于。正确索引，表大小对速度的影响很小。当没有可行的索引时，大小很重要。所以... 考虑一下SELECTs 现在，甚至在您设计表格之前。当然这是工作量的两倍，但它很有用——用于学习、练习和帮助做出决定。