首先，是类型操作的不同，类似于wiLdGoose这样做法的“时间计算”实质上是整形之间的操作（而且这个整形非常大，长度为10）。更有甚者，将时间戳设置为VARCHAR(10)，由此引发的效率问题不言而喻。
至于时间计算和整形计算乃至字符串的计算的效率问题，这篇文章非常能说明问题。
其次，是逻辑方面的操作问题。这是使用时间类型的优势，尤其是在需要高精度的项目上。比如需要“前一个星期的数据”和“获得从数据库建立以来每个星期一的数据”，这样的操作如用wiLdGoose兄的做法复杂度可想而知。
最后，就是直观不直观的问题，可以理解的是我们的大脑是不会直接将这一大串的时间戳转换成日期格式的。相比而言，直接使用时间类型明显就直观得多（它本身就是时间格式）。
而我目前的团队也还是在使用类似的方法。本人对于类似技术细节也争执了良久，但由于岗位和决定权的问题，团队还是无法采纳本人的意见，甚为遗憾。
MySQL定位为简单快速的DBM自然能迅速的驾驭，但是另一方面很容易造成不会深入下去的局面。对于此，我们更应该注意每一项的数据库设计细节，一项产品不断添加新的功能到最后都是面向应用的。
最后，附MySQL官方的时间和日期函数的手册。
