什么时候可以压扁数据库?

时间:2013-09-18 14:58:21

标签: mysql hibernate database-design

我们围绕业务模型设计了数据库,每种业务类型都有一个表。但是,由于具有几个相似类型的单独表会导致性能问题,我正在考虑将几个相关表展平为一个带有鉴别器列的表,以识别每行的实际子类型。

我们的规范化模型的问题:

  • 其他几个核心表具有对这些子类型之一的多态引用,这些子类型需要联合查找以确定哪个表包含其引用的对象
  • 在这些子类型的并集中搜索和索引(一种常见操作)效率低下
  • 在多个表中复制语义相同的列

由于我们使用的是Hibernate和JPA,因此多态连接很困难,我们无法使用视图。

扁平化的缺点:

  • 我们的代码现在负责这些子类型的引用类型完整性,而不是数据库中设置的外键限制
  • 对于该类型的无关列,每行都有空值
  • 向任何子类型添加列都需要在整个表中添加一列
  • 特定于一个子类型的列不能标记为非null

This related SO question建议保持标准化设计,但在他们的情况下,子类型只共有100列中的10列。我们的展平表总共包含15列:每个子类共享11个,其他4个由多种类型共享(但不是全部)。

这是一种平整有意义的场景吗?

0 个答案:

没有答案