原文：http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/

译者：cxhuan 

        想我在一些演讲中说的一样，提升系统性能的最好的方式是千万不要做“傻事”。我并不是说你或者你的开发者是傻子，而是说人们容易忽略这些决策的隐形问题，没有意识到一些问题的可维护性。作为一个咨询顾问，这种案例我见多了，还没见过有谁能够很好地解决这个问题。

图片，文件和字节数据
        你们的数据库支持大容量二进制数据，所以你觉得应该把你的文件放进去，对吗？完全不是这样的。这样甚至不方便多种数据库语言的绑定。将文件存储在数据库中有几个问题：
        读/写数据到数据库总比文件系统慢
        数据库备份量巨大而且更耗时
        访问文件时要通过应用层和数据库层
        最后两条是真正的祸害。将缩略图放进数据库？很好，但是现在你无法用代理器或者其他的轻量级Web服务器来支撑他们了。
省省吧，存储你硬盘文件上的一个相对路径到数据库或者用类似于S3或CDN的东西代替就可以了。

临时数据
        统计度量数据，GPS位置信息，会话数据，任何只使用短时间或者经常变换的数据都是临时数据。如果你发现自己花大量时间去删除只使用一个小时、一天、一周的表格，那么你就用了错误的工具了。使用 redis, statsd/graphite, Riak或者任何更适合的工具去工作吧。这种方法同样适用于聚合性的临时数据。与其预定时间等挖掘机赶到你那里去挖个坑种番茄，还不如在车库里那个铁铲出来挖来的快。做事要选用合适的工具。

日志
        这个日志表面上看好像是可以放进数据库的，而且那个“我可能在未来需要用复杂的查询语句来查询他们”的言论好像更得人心。将日志存进数据库不可怕，可怕的是将他们和其他产品信息放进同一个数据库。也许你对日志比较保守，一般将每个Web请求放进同一日志行中。那样仍然会对网站的每一个动作产生一条插入记录来和用户争用资源。将你的日志级别设为冗余或者调试来代替用诸如Splunk，Loggly或者旧的简单的文件系统，不要放进产品数据库。你需要偶尔的检查他们，有时候甚至需要写一小段代码来找数据，这比在你的系统中放入固定资源要容易。
        你是独立个体，你的问题与众不同，所以你做了其中一项也无所谓。不，事实真不是这样的。相信我。