数据库里不要这样做!

 

*不要把有意义的列作为表的主键。

    有含义的列，即便不会重复，也不要作为表的主键。

    原因：

    1.主键可能会对应到许多其他表的外键。如果这个有含义的列中的某条数据，因为某些原因需要修改。这样就会导致数据库中的许多其他表中的数据也需要发生修改。

    2.有含义的列中的数据大多数是外部输入。而外部输入有可能会出现失误。从而造成数据会发生重复。

 

 

 

 

【以下转自《三种东西永远不要放到数据库里》】

    我已经在很多演讲里说过，改进你的系统的最好的方法是先避免做“蠢事”。我并不是说你或你开发的东西“蠢”，只是有些决定很容易被人们忽略掉其暗含的牵连，认识不到这样做对系统维护尤其是系统升级带来多大的麻烦。作为一个顾问，像这样的事情我到处都能见到，我还从来没有见过做出这样的决定的人有过好的结果的。

 

*图片，文件，二进制数据

    既然数据库支持BLOB类型的数据，把文件塞进BLOB字段里一定没有错了！？错，不是这样的！别的先不提，在很多数据库语言里，处理大字段都不是很容易。

 

    把文件存放在数据库里有很多问题：

• 对数据库的读/写的速度永远都赶不上文件系统处理的速度
• 数据库备份变的巨大，越来越耗时间
• 对文件的访问需要穿越你的应用层和数据库层

    这后两个是真正的杀手。把图片缩略图存到数据库里？很好，那你就不能使用nginx或其它类型的轻量级服务器来处理它们了。

    给自己行个方便吧，在数据库里只简单的存放一个磁盘上你的文件的相对路径，或者使用S3或CDN之类的服务。

 

 

*短生命期数据

    使用情况统计数据，测量数据，GPS定位数据，session数据，任何只是短时间内对你有用，或经常变化的数据。如果你发现自己正在使用定时任务从某个表里删除有效期只有一小时，一天或数周的数据，那说明你没有找对正确的做事情的方法。使用redis， statsd/graphite， Riak，它们都是干这种事情更合适的工具。这建议也适用于对于收集那些短生命期的数据。

    当然，用挖土机在后花园里种土豆也是可行的，但相比起从储物间里拿出一把铲子，你预约一台挖土机、等它赶到你的园子里挖坑，这显然更慢。你要选择合适的工具来处理手头上的事。

 

 

*日志文件

    把日志数据存放到数据库里，表面上看起来似乎不错，而且“将来也许我需要对这些数据进行复杂的查询”，这样的话很得人心。这样做并不是一个特别差的做法，但如果你把日志数据和你的产品数据存放到一个数据库里就非常不好了。

    也许你的日志记录做的很保守，每次web请求只产生一条日志。对于整个网站的每个事件来说，这仍然会产生大量的数据库插入操作，争夺你用户需要的数据库资源。如果你的日志级别设置为verbose或debug，那等着看你的数据库着火吧。

    你应该使用一些比如Splunk Loggly或纯文本文件来存放你的日志数据。这样去查看它们也许会不方便，但这样的时候不多，甚至有时候你需要写出一些代码来分析出你想要的答案，但总的来说是值得的。

    可是稍等一下，你是那片不一样的雪花，你遇到的问题会如此的不同，所以，如果你把上面提到的三种东西中的某一种放到了数据库里也不会有问题。不，你错了，不，你不特殊。相信我。

 

【以下转自《程序员应该知道的数据库设计的两个误区》】

在几乎所有的企业级应用程序中，包括各种MIS、ERP、CRM等等，都会使用数据库，这样的好处是显而易见的，很容易地实现了数据层和业务逻辑层的分离，而且对于性能的优化也在一定程度上提供了便利。然而，在我所经历过的项目中，某些数据库的设计会存在一些问题，尤其普遍的就是下面将要描述的这两点，个人觉得是应该避免的误区，总结出来与大家讨论。

误区之一 备用字段

现象描述：

在数据表中，不仅设计了当前所需要的字段，而且还在其中留出几个字段作为备用。

比方说，我设计了一个人员表（Person），其中已经添加了各种必要的字段，包括姓名（Name）、性别（Sex）、出生年月日（birthday）等等。大功告成之后，我忽然想到，将来系统中应该还会有很多其它与人相关的内容吧，比方说毕业院校，比方说工作单位等等，尽管现在根本不需要填写，以后可能还是会用到的吧。拍脑袋一项，那就加入5个varchar2型的字段，分别叫做Text1、Text2……Text5，然后又想，应该还有一些日期型的字段需要备用，就又建立了三个date型的字段，分别起名叫做date1、date2、date3，……

原因分析：

大家应该已经看出问题了，在这个数据表中存在大量暂时无用的字段，我们可以称之为备用字段，它们的作用是什么呢？就是以防万一，防备可能的情况。

这似乎可以叫做防患于未然，等到时候需要的时候，就不需要在表中增加新的字段了，而且这样做的话，一个表的数据应该会被存储在相邻的物理空间中，这对于性能也是有好处的。

另外的原因就是，在古老的数据库中，如果改变数据库的定义（包括增加字段、改变字段的类型、删除字段等等），那么其中所有的数据就会丢失，所以这项工作非常麻烦，我们需要先建立临时表，将数据备份出来，然后创建新表，将数据导入其中，最后再删除原来的表。

问题所在：

这样的做法对于项目会导致很多问题，而且原先想要解决的问题并不一定能够解决，不信的话，请往下看。

问题一：增加大量备用字段，必定会浪费很多空间，尽管其中可能都没有具体的数据，但是仅仅是空字段也会占据一定的空间的。

问题二：由于命名的特点，如果没有完善的文档管理流程，用不了多久（可能也就是两三年），就没有人能够说清楚到底哪个字段代表的是什么意义了。就算有文档管理，这些管理工作也会比较麻烦，而且在每次使用的时候都需要申请，还有可能会出现冲突的情况。

问题三：增加了这些备用字段就真的会够用吗？不一定，因为我们只是每个类型的字段留出几个备用，如果数量超过，或者要使用特殊的、不常用的类型的时候，还是需要增加新的字段。比方说在上述的Person表中，我们要存储照片，那么可能就要增加一个blob类型的photo字段，这在初期设计的时候可不一定会留出这样的备用字段。而且如果没有完善的管理，谁又能说清楚倒底哪个字段已经被使用，哪个字段还可以使用呢？到时候还不是要增加新的字段。

解决方案：

其实上面的这种设计方式就是一种“过度设计”，我们应该做的就是“按需设计”，在经过详细有效的分析之后，在数据表中只放置必要的字段，而不要留出大量的备用字段。

当需要增加相关的信息的时候，就要具体情况具体分析：

如果数量很少，而且信息的性质与原表密切相关，那么就可以直接在原表上增加字段，并将相关的数据更新进去。

如果数量较大，或者并非是原表对象至关重要的属性，那么就可以新增一个表，然后通过键值连接起来。

对于表的数据的存储位置所导致的性能问题，我们可以通过在特定时间对数据库的数据进行重组来解决，而这项工作对于长期运行的数据库来说，也是需要定期进行的。

 

误区之二 有意义的编码

现象描述：

使用有意义的编码作为一条记录的ID，甚至作为数据库的主键存在，例如，一个员工的编码设置为0203004，其中02代表员工所在分公司，03代表员工所在部门，004代表员工进入到该部门的序号。

原因分析：

ID的设置方式大概有以下几种，一种是纯粹的流水号，从1开始，每次加1，或者对其将以改进，将数字转换成为字符串的格式，比方说“0000001”；一种是无意义的随机编码，比方说GUID；还有一种就是有意义的编码，特定的位数会代表一定的意义。

我想之所以大家这么喜欢使用这种方式，主要是因为想要从编码中就能够得到一些信息，甚至有些程序中还有专门的对编码进行解析的模块。就像我们的身份证号码一样，看到身份证号就可以知道办身份证时的所在地、生日、性别等信息。

问题所在：

其实有意义的编码会导致很多问题，请看：

问题一：对编码资源的浪费。如果是纯粹的流水号，那么从1到10000就可以代表一万条记录，但是，如果使用有意义的编码，很可能1000条记录就会让五位的编码不够用。我就遇到过真正的情况，我们公司的投保单号码的第一位就是有意义的，代表的时该投保单所属的渠道，后面跟着很长的一串数字（9位）。理论上来说，这些编码永远都不会用完，但是，最开始的三个渠道使用的是1、4、7三个编码，但是一次新保险法的实行，导致原有的投保单作废，于是又启用了三个数字2、5、8，接下来公司改名，三个渠道又分别将投保单报废，重新启用新的开头数字，就这样，短短的几年间，所有的投保单号码全都被用完了，其实打印出来的投保单不过100万张。

问题二：不一定是唯一的，难以作为主键。想一下，我们的身份证号码就是这样的。原先15位的时候，后三位是序号，而男性会使用奇数，女性会使用偶数，这样就是说，一个地区同一天生日的人，男女都不能超过500人，否则就会导致号码的重复，尽管出现这种现象的概率比较低，但是还是客观存在的。

问题三：代表的意义不一定准确。比方说用带有意义的编码来为员工定义工号，其中可能会有部门、职务等等意义，但是如果员工在部门间发生了调动，或者职级发生了改变，是否需要改变他的编码呢？改变吧，那么所有的历史数据都要随之修改一次，工作量会非常大；不改变吧，那么代表的意义就不再准确，我们就无法从编码中得到该员工准确的信息。

解决方案：

所以，对于编码，非常不建议使用有意义的编码，要么使用纯粹的流水号，但这样可能需要定义一个范围比较大的类型，对于海量记录的数据，可能会不够用；那样的话就可以使用GUID，这样编码永远都不会重复，而且会有大量的编码资源可用。

从上面的两点我们可以看出，在数据库设计的过程中，有一些在非常多系统中都使用了，但是却带来了很多问题的方法，对于这种情况，我们就应该仔细思考，然后痛下决心，坚决抵制。