数据库设计坏味道

数据库设计坏味道：

之前讨论了代码中的坏味道，这个很多人讲过，也比较常见。本文讨论的是数据库设计中的坏味道。
很多人会忽略数据库设计中的坏味道，而实际上我个人经验而言，不好的数据库结构，会造成灾难性的后果，比不合理的代码的危害程度高很多。因为在业务运行以后，数据库的修改成本非常高，会出现修修补补的情况，以至于屎山越堆越高。

常见的数据库坏味道：

1. 大宽表
   开玩笑讲，如果可以，我能用一张表搞定一个业务，当然是不行的。但有时候也不需要完全按三范式拆分得特别零散，那怎样判断呢？我个人的经验是：如果模型A与模型B是1：1严格对应的且B模型的字段较少，那两个模型建一张表也未尝不可。
   例如常见的学生班级举例。如果班级只有一个属性，叫班级名称，那也不必建立单独的班级表与学生表关联，直接存储班级名称就好。并且更加直观
2. 全是varchar
   这种情况是笔者实际中见过的。如果了解mysql的存储相关原理，就知道varchar在存储的时候需要单独空间存储内容长度。对空间和效率都不友好。合理的字段类型设计可以达到小而快的目标。
3. 逻辑抽象混乱
   最常用的类比是，我们在设计或新建一个表的时候，一定是有某个业务模型与之对应的。如果一张表对应了多个模型，例如第1条中的学生班级表，一张表同时对应了学生和班级，就应该引起警惕，慎重考虑如此设计的必要性
4. 过多依赖某种特性
   这个也是笔者的经验之谈。例如mysql的索引、视图等。这两项特性都可以极大提升查询效率，但过度依赖造成索引、视图过多，会造成更新效率低下，应该引起警惕。<