上一篇文章里面提到怎么样写sql，怎么样报表排查错误的方法，引起许多小伙伴们的共鸣。微信群里讨论了一会，舆论的方向会就转向了后台表结构的“糟心设计”，看来大家对此都是深有感触！我写了这么多年的sql，也啃了不少代码，其实对这些逻辑不通顺利、缺胳膊少腿、命名不规范等等问题，我也是深有感触！
我也先来吐槽一下，我认为最不合理的设计 ，像"天书一样的命名"的表结构，好像有些“医保平台”就是这样命名（AKA01、AKA02、BAA等）的，我不知道他们是出于何种目的要这样做，如果我是开发总监是绝对不允许这种设计产生，除非有足够多信服理由说服我，我看除了“害惨自家兄弟”，看不到第二个好处。有人说我这样做是为了数据库安全，数据库的安全是用不规范的命名就可以解决？数据库安全的关键是对资源的访问权限控制，比如DBA拥有超级权限访问所有资源，普通用户拥有普通权限访问授权资源，一旦获取数据库资源访问权限，还有什么安全可言；有人说怕别人sql注入，这种问题早就有成熟的解决方案应对。
"天书一样的命名"坏处非常多，除非是开发国防用途的软件（每个环节都需要安全），一般都用不着这样做。第一个坏处：开发效率低、运维效率低，人人捧着一本字典对照手册；第二个坏处：如果有人离职了，接手的人痛不欲生，写的是啥；第三个坏处：产品开发周期长、成本高、产品稳定性都会受影响。
怎么样设计合理的HIT数据库表结构，我一直在寻求答案，通过不断学习，自己写软件实践，研究不同公司的表结构，接下来看看我对这个问题的分析。
首先要了解一个HIT软件要运行起来，其实需要2部份的数据，一部分是业务数据（发票表、医嘱表等），另一部分是基础字典数据（科室基础表、职工基础表等）；还要了解一下数据库表设计理论原理知识：范式（大白话怎样减少信息冗余）简称1NF,2NF,3NF等。
对于“业务数据”表结构设计---尽可能接近 1NF
对于一些不经常变动基础的数据进行冗余保存到业务表，比如，保存“发票类别代码+发票类别名称”、“医生工号+医生姓名”、“科室代码+科室名称”、“结算方式+结算方式名称”等。这样做的目的，1、尽可能避免多表查询，考虑效率，因为业务数据是要被经常访问的，能访问一张表搞定，就不要访问2张表；2、保持历史数据独立完整性，比如，某位员工离职了，就把操作权限连同基础数据一起删除了，依然不影响历史数据查询。我们医院就有“结算方式”被禁用，导致有些系统无法读不出来历史数据了，原因是原来在开发软件时候，由于没有冗余存储，直接关联了基础表，导致读不出来。
对于“基础字典数据”表结构设计---尽可能接近 3NF（尽量最小的修改代价原则）
范式级别越高，信息冗余就越小，但一般到3NF就可以，尽可能符合“尽量最小的修改代价原则”。基础数据由于记录少，多表查询一般不会有执行效率问题，数据冗余越小我们维护越方便，出错概率就越小，系统稳定性高。
以上就是我对怎么设计合理的HIT数据库表结构设计的理解， 我看到有些HIT公司后台表结构就是按照这2种原则来处理的，好似有种英雄所见略同的感觉，写sql查询起来轻松+愉快，而且历史查询数据不会出现“缺胳膊少腿”的现象。
冯火 2019-07-01
网友评论