上次对于 MySQL 方面已经有的 一些总结 ，但是昨晚 wiLdGoose 兄 说他也碰到同样的问题，但是无法解决。结果经过种种的假设和判断以后，到最后发现原来是 Zend Studio 的时区配置问题（我狂汗ing）。而在和他讨论期间也谈到了很多关于 MySQL 的细节问题，还是记录一下当作备忘比较好。这篇文章同时也做说服 wiLdGoose 兄用。

由于曾经和他是同一个团队的，所以对于其我很熟悉他那「洁癖」的做法，对于他的很多的观点我也非常的赞同；但是有一件非常不理解的地方就是设计数据库的时候总是会回避使用 Date/Time 类型。他的做法是将时间相关的字段设置为 INT(10) 类型，然后用 UNIX 时间戳来存储。而我本人对于这点做法非常的不赞同：

首先，是类型操作的不同，类似于 wiLdGoose 这样做法的「时间计算」实质上是整形之间的操作（而且这个整形非常大，长度为 10）。更有甚者，将时间戳设置为 VARCHAR(10) ，由此引发的效率问题不言而喻。

至于时间计算和整形计算乃至字符串的计算的效率问题， 这篇文章 非常能说明问题。

其次，是逻辑方面的操作问题。这是使用时间类型的优势，尤其是在需要高精度的项目上。比如需要「前一个星期的数据」和「获得从数据库建立以来每个星期一的数据」，这样的操作如用 wiLdGoose 兄的做法复杂度可想而知。

最后，就是直观不直观的问题，可以理解的是我们的大脑是不会直接将这一大串的时间戳转换成日期格式的。相比而言，直接使用时间类型明显就直观得多（它本身就是时间格式）。

而我目前的团队也还是在使用类似的方法。本人对于类似技术细节也 争执了良久 ，但由于岗位和决定权的问题，团队还是无法采纳本人的意见，甚为遗憾。

MySQL 定位为简单快速的 DBM 自然能迅速的驾驭，但是另一方面很容易造成不会深入下去的局面。对于此，我们更应该注意每一项的数据库设计细节，一项产品不断添加新的功能到最后都是面向应用的。

最后，附 MySQL 官方的 时间和日期函数的手册 。

抱歉，此篇 Blog 无价值， 详情见此

很多的时候用户需要等待你「臃肿」的 Javascript 代码处理完成（Web 2.0 的特色）。期间或许加入一个类似于进度条的东西让用户有点「安慰」。这个东西实现起来并不复杂，无非就是获得总的处理条目，然后获得一个百分比，再显示输出。

通过我们伟大的 CSS，可以实现非常漂亮的进度条样式。加上 Javascript 的效果，就可以完全「欺骗」我们的用户，让他们有耐心等待浏览器处理完成。上述的原理已经知道了，那么就可以直接看代码了。本人使用的还是 jQuery 框架 ，因为这样简短的代码可能会更容易理解。

当然这个控件还有很多需要完成的地方，我仅仅是提供了一种 遵循 Web 标准 的实现思路。废话不多说，有时间的话可以点击这里看下 Demo ，或者将这个代码 打包下载 。

本来已经 计划 好圣诞节出去 Happy 一下的，但是偏偏杭州该死的天气却下起了雨来，真的是一件非常郁闷的事情。到现在我都弄不清楚西方的圣诞节和国人有什么关系，但是几乎很多网站都不一的将自己的 Logo 改得非常的「圣诞」。

本人无聊，下面逐一的点名。首先是 wiLdGoose 兄 ，他的圣诞版 Logo 非常的强大，经董事会（不好意思，就我一人）一致通过，被评为本年度最花哨的 Logo。

70 兄弟 也非常低调地将自己的 i 上的一个点改成了小红帽的样子。嗯，简约而不简单，这个偶稀饭。

压轴出场的自然是最精彩的，下面就是 Gracecode.com 的圣诞版 Logo（和 70 兄的看起来很像？！不会吧，人家是 i 上面的，我是 G 上面的）。按照 wiLdGoose 兄弟的话说就是「非常的 G」。

各大网站的 Logo 几乎都有变动，比如 淘宝 、 Yupoo 等等，无非就是围绕「红帽子」、雪地、麋鹿（不是《海贼王》那个）等等，大家自己去挖掘了。「最 G」的自然是 Google 那疙瘩，地球人都知道这伙人的涂鸦嗜好已经成为他们的企业文化了。

PS: 但愿这篇无聊的文章没有吓倒小朋友和花花草草。