图片，文件。二进制数据
既然数据库支持BLOB类型的数据，把文件塞进BLOB字段里一定没有错了！？错，不是这种！别的先不提，在非常多数据库语言里，处理大字段都不是非常easy。
把文件存放在数据库里有非常多问题：
●对数据库的读/写的速度永远都赶不上文件系统处理的速度
●数据库备份变的巨大。越来越耗时间
●对文件的訪问须要穿越你的应用层和数据库层
这后两个是真正的杀手。把图片缩略图存到数据库里？非常好，那你就不能使用nginx或其他类型的轻量级server来处理它们了。
给自己行个方便吧，在数据库里仅仅简单的存放一个磁盘上你的文件的相对路径。或者使用S3或CDN之类的服务。
短生命期数据
使用情况统计数据，測量数据，GPS定位数据，session数据，不论什么仅仅是短时间内对你实用，或常常变化的数据。假设你发现自己正在使用定时任务从某个表里删除有效期仅仅有一小时，一天或数周的数据，那说明你没有找对正确的做事情的方法。使用redis，statsd/graphite， Riak。它们都是干这样的事情更合适的工具。
这建议也适用于对于收集那些短生命期的数据。
当然，用挖土机在后花园里种土豆也是可行的，但相比起从储物间里拿出一把铲子。你预约一台挖土机、等它赶到你的园子里挖坑，这显然更慢。
你要选择合适的工具来处理手头上的事。
日志文件
把日志数据存放到数据库里，表面上看起来似乎不错。并且“将来或许我须要对这些数据进行复杂的查询”。这种话非常得人心。这样做并非一个特别差的做法。但假设你把日志数据和你的产品数据存放到一个数据库里就非常不好了。
或许你的日志记录做的非常保守，每次web请求仅仅产生一条日志。对于整个站点的每一个事件来说，这仍然会产生大量的数据库插入操作，争夺你用户须要的数据库资源。
假设你的日志级别设置为verbose或debug，那等着看你的数据库着火吧。
你应该使用一些比方Splunk Loggly或纯文本文件来存放你的日志数据。这样去查看它们或许会不方便。但这种时候不多，甚至有时候你须要写出一些代码来分析出你想要的答案，但总的来说是值得的。
但是稍等一下，你是那片不一样的雪花，你遇到的问题会如此的不同，所以。假设你把上面提到的三种东西中的某一种放到了数据库里也不会有问题。不，你错了，不，你不特殊。相信我。
译文地址：http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/