绝对范式or适度冗余

对于数据库三范式,脑子里虽然已经记不太清具体是如何描述的,但是做数据库设计的时候,往往遵循的就是三范式原则;

因为没有冗余的数据结构,符合我们的编程逻辑,比如这个:

account = Table('account', con.metadata,
    Column('id', Biginteger, primary_key=True),
    Column('name', String(128), doc='户名'),
    info = {'doc':'账户表'}
)

account_entry = Table('account_entry', con.metadata,
    Column('id', Biginteger, primary_key=True),
    Column('account_id', BigInteger,ForeignKey('account.id'), doc='账户ID'),
    Column('amount', BigInteger, doc='发生额'),
    Column('balance', BigInteger, doc='余额表'),
    info = {'doc':'账户发生明细表'}
)

账户归账户,明细归明细,明细表里只存在账号表的主键,清晰明了。

然而,实际生产中,我们可能是这么设计的:

account_entry = Table('account_entry', con.metadata,
    Column('id', Biginteger, primary_key=True),
    Column('account_id', BigInteger,ForeignKey('account.id'), doc='账户ID'),
    Column('account_name', String(128), doc='户名'),
    Column('amount', BigInteger, doc='发生额'),
    Column('balance', BigInteger, doc='余额表'),
    info = {'doc':'账户发生明细表'}
)

发生了哪些变化?
我们把账户表的名称放到了明细表里;

程序员逻辑肯定会想:怎么能把户名放到明细表里?账号表的户名发生变化怎么办?

诚然,我们都不喜欢这样的数据库设计,但为什么还是要这么做呢?

【这与关系型数据库的join问题有关】
因为join慢呀!
系统需要查询所有账户的明细,需要显示户名。

如果采用三范式,那必须要联表,既需要join,对于几万几十万的数据量来说,还不成问题, 但对于几百几千万甚至亿级的数据量,怕是系统要撑不住噢。

这个时候,只要再明细表里面加一个户名字段,既能够单表查询,能大大提升查询的效率。

所以,范式固然好,看着舒服,扩展性也好,但针对实际的应用场景,有时候还是需要对适度冗余进行妥协。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

友情链接更多精彩内容