允许传递依赖的一种情况

传递依赖违反了数据库设计范式,但有时允许传递依赖,可以获得比较好的直观性

比如, <公司,部门,员工>这种关系,可以设计两张表:

    <company-id, department-id, employee-id>

和  <company-id, department-id>

是的,这样会有冗余:<公司,部门>关系在两张表里都存在。

这样会不会出问题? 如果一个部门永远跳不出它所属的公司,其实这种冗余就无所谓。否则,第二张表里的re-match会引发第一张表的批量改动。

那这样做又有什么好处?好处就是避免一次表连接。如果消除了传递依赖,那么查询员工所属部门时就得连接两张表: <company-id, department-id> 和 <department-id, employee-id>。

如果你的业务中,“部门”的概念非常弱,弱到只相当于一个标签的话,你就可以采取这种反范式的设计。

如果“部门”下面还分“子部门”,并且组织架构重整经常发生的话,那你还是不要这样玩了。老老实实按范式走,可以使编码更优雅更干净。

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.