数据库表设计的大忌.

版权声明:本文为 走错路的程序员 原创文章,欢迎转载。 https://blog.csdn.net/phker/article/details/81558665

很多的程序员,总是会犯这种错误..导致后来系统越来越烂..
越来越烂,基本上都是这几个原则没有把握住.
第一个大忌,懒, 不想新增字段, 使用已有字段存放新的数据.
举个例子, 客户姓名, 客户代号,客户ID, 可能有的系统设计的时候,只有客户姓名和客户ID, 没有客户代号. 然后某一天在跟其它系统对接的时候发现, 咦, 需要存放客户代号.对方发过来的是客户代号..没有客户ID… 老板催的又急,急着出结果.. 脑袋一热, 不管了. 先上了再说… 先把客户发过来的客户代号放到客户ID里吧.. 反正能运行起来, 系统跑起来再说….

第一个大忌,一个字段内,存放两种意义的数据, 违反了 数据库设计的 第一范式 ..
举个例子, 医院系统里面, 病人的编号. 这个字段经常会存, 病人的住院号, 有的又存医保代号,有的又存身份证号, 还有的存电话… 虽然都可以当作编号…后期的数据分析怎么做?
而违反这个规则的, 往往都是后期, 后期在维护的时候脑袋一热就存进去了… nmd. 我看到这样的数据只想杀人….

第三个大忌, 字段名跟实际存放的内容不一致.
这是一个非常大的隐患. 今天很清楚, 这个字段存放的是什么东西… 过些日子, 就不知道了. 按照字段意思来理解, 然后把其它东西也存进来了. .. 结果就开始乱糟糟了.

第四个大忌, 缺东少西,
一个表看上去, 30+个字段.主要的几个字段存的数据都不全. 不是少这个就是少那个, 应该要存的数据. 偏偏有的模块会存, 有的模块又不存. 让后来人,怎么去查询呢? 是该相信还是不该相信呢?这种数据表一般是那种很多很多年的老系统经过很多人的修改越来越烂的系统会存在这种情况.

第五个大忌, 死搬教条式的, 向数据库的设计范式靠拢. 导致数据越来越少,系统越来越复杂..
数据库设计的3大范式, 其中有一条, 被非常多的程序员坚持着. 而这种坚持, 在今天看来, 完全就是死脑筋… 举个例子, a->b->c->d 4个表, 数据创建顺序分别是, 现有a的数据,再依次创建b的,c的,和d的.
那么按照数据库设计范式, b里面有a的主键, c里面有b的主键, d里面有c的主键….. 如果仅仅是这样.以后的程序员要累死的.
合理的数据库设计, 一定是 a的字段b里面都有, b的字段c里面都有, c的字段d里面都有.
数据应该是越来越多的, 怎么能越来越少了呢? 甚至是要流水似的反查回去呢?

一个优美的数据表是一切系统的良好基石, 表都设计不好的,程序员. 能搞出什么像样的系统?? 搞来搞去搞自己…

我写数据库相关类的系统, 10多年了. 可以说,各种各样的烂系统都见过… 时间越久的系统确实烂的越严重… 基本上都是上面的这几个问题…

一个合格的优美的数据库表结构, 应该是,一张数据流水图.

这里写图片描述

枝叶上的应该是基础信息表.

而主干则是业务信息主表.

这里个主干的粗壮并不单单是数据量的增多, 字段也应该是越来越多,越来越齐全的.
信息流着流着就没了. 这样的系统活不久. 早晚成 “死海”

在这里我甚至在想, 我们目前的关系型数据库还有一大可以改进的点.
每次我们查询数据都要 left join . 做表间关联. 是不是可以把这种表间关系, 先维护设计好. 固定在数据库设计之中. 而查询的时候自动根据这个关系解析, 查询出相应的结果.. 这样我们的数据库查询语句会更简单. 插入和更新也会更简单.

猜你喜欢

转载自blog.csdn.net/phker/article/details/81558665
今日推荐