三种东西永远不要放到数据库里

改进你的系统的最好的方法是先避免做“蠢事”。 我并不是说你或你开发的东西“蠢”,只是有些决定很容易被人们忽略掉其暗含的牵连, 认识不到这样做对系统维护尤其是系统升级带来多大的麻烦。 作为一个顾问,像这样的事情我到处都能见到,我还从来没有见过做出这样的决定的人有过好的结果的。 图片,文件,二进制数据 既然数据库支持BLOB类型的数据,把文件塞进BLOB字段里一定没有错了!?错,不是这样的! 别的先不提,在很多数据库语言里,处理大字段都不是很容易。 把文件存放在数据库里有很多问题:
  • 对数据库的读/写的速度永远都赶不上文件系统处理的速度
  • 数据库备份变的巨大,越来越耗时间
  • 对文件的访问需要穿越你的应用层和数据库层
这后两个是真正的杀手。 把图片缩略图存到数据库里?很好,那你就不能使用nginx或其它类型的轻量级服务器来处理它们了。 给自己行个方便吧,在数据库里只简单的存放一个磁盘上你的文件的相对路径,或者使用S3或CDN之类的服务。 短生命期数据 使用情况统计数据,测量数据,GPS定位数据,session数据,任何只是短时间内对你有用,或经常变化的数据。 如果你发现自己正在使用定时任务从某个表里删除有效期只有一小时,一天或数周的数据, 那说明你没有找对正确的做事情的方法。 使用redis,statsd/graphite, Riak,它们都是干这种事情更合适的工具。 这建议也适用于对于收集那些短生命期的数据。 当然,用挖土机在后花园里种土豆也是可行的,但相比起从储物间里拿出一把铲子, 你预约一台挖土机、等它赶到你的园子里挖坑,这显然更慢。 你要选择合适的工具来处理手头上的事。 日志文件 把日志数据存放到数据库里,表面上看起来似乎不错,而且“将来也许我需要对这些数据进行复杂的查询”, 这样的话很得人心。这样做并不是一个特别差的做法, 但如果你把日志数据和你的产品数据存放到一个数据库里就非常不好了。 也许你的日志记录做的很保守,每次web请求只产生一条日志。 对于整个网站的每个事件来说,这仍然会产生大量的数据库插入操作, 争夺你用户需要的数据库资源。 如果你的日志级别设置为verbose或debug,那等着看你的数据库着火吧。 你应该使用一些比如Splunk Loggly或纯文本文件来存放你的日志数据。 这样去查看它们也许会不方便,但这样的时候不多,甚至有时候你需要写出一些代码来分析出你想要的答案, 但总的来说是值得的。 可是稍等一下,你是那片不一样的雪花,你遇到的问题会如此的不同, 所以,如果你把上面提到的三种东西中的某一种放到了数据库里也不会有问题。 不,你错了,不,你不特殊。相信我。 转自php100

开发者,别让任何人绑架你的工作节奏

作为一个软件开发者,你的工作内容远远不止写代码。还有一些是你职责范围内的事:
预估工作周期 理解你没写过的软件的功能 把复杂的问题简单化 把复杂的问题分解成若干个小问题 调整代码,为迭代预留空间 发现并修复漏洞 上述问题与其他成员协作完成 如果你直接和你的用户交互,还有更多的建议: 把用户需求翻译成改进计划; 深入浅出,把复杂的意思用简单的方式向用户传达; 明晰每一个尚待解决的问题。
但是在这些职责之上,最重要的是在了解目标用户的基础上设定目标。 设定目标的意思是对工作的节奏和流程保持始终的掌控力,保证你的工作可以进行下去。这意味着要做风险预计,并让用户知晓潜在风险,不至于风险降临时措手不及,这就需要设定一系列的规则和流程。 如果方法得当,有没有设定目标在某些情况下可以造成煎熬和享受工作两种截然不同的结果。 作为一个开发者,你就是一个工匠,可以使用任何的工具去创造,不能让别人的期望凌驾于你的创作自由之上。你必须自主把控这个创造的流程。 如果你让用户的意志凌驾于你的创造之上,很可能会有以下结果: 你的用户会“认为”应该什么时候可以完成工作,那时候你可能只能拿出半成品,无法满足用户预期; 如果你的工作没有按照用户预期的时间节点走,他们就会觉得沮丧,丧失信心; 用户的预期会迫使你做一些你自己并不认同的东西。 当然,最理想的情况是用户会尊重你每一次设定的目标,但这种情况可遇不可求。总之无论何时记住:在软件开发的过程中,你才是那个决定什么时候达到什么目标的人。 转自php100