不但在数据库的移植问题上，CHAR类型日期比DATE类型日期拥有绝对的优势，在数据的导入/导出，数据传输等方面，CHAR类型日期比DATE类型日期也具有较多的优势。字符型的数据可以直接不失真地用文本或XML表示，而Date类型导出为文本时，如果不指定好转换格式往往难于处理，如2001-01-01的Date数据在转换为文本时，可能变为1st Mon 2001，也可能为2001-01-01 00:00:00 ，甚至可能是01-01-01。这样，在导入时显得难以操作，因为导入/导出都需要指定好日期格式。

6、总结

有一句很经典的关于软件设计的话：如果你的程序逻辑变得很复杂，也许并不是问题域本身的复杂度造成的，往往将归因于设计上的缺陷和瑕疵。同样一个问题，采用不同的策略，往往造成大相径庭的解决复杂度。Spring框架功能强大，我本以为代码一定很复杂，但是当我研读了Spring框架的代码时，才诧异地发现Spring框架的源码很少有超过300行代码的类，类和方法大多简洁明了，真是应了那句大巧若拙，大道至简的话了。

在库表设计时，日期字段究竟是采用CHAR类型日期还是DATE类型日期，在作出选择时，需要考虑在程序逻辑中该数据的加工操作逻辑，毕竟表字段是需要在程序逻辑中使用和操作的，而非仅仅做一个简单的记录而已。

通过上文的分析，我们发现CHAR类型日期可以在较大的程度上简化程序的开发，并且充分利用索引，获取较好的性能。但又一个问题产生了，既然CHAR类型日期这么不好用，各数据库又都提供了Date日期格式，是否Date数据类型就成了尸位素餐的摆设了呢？换言之，Date数据类型适合在什么场合使用呢？笔者个人的建议是，在几乎任何时候都不要使用Date类型作为表字段类型，Date类型仅在存储过程，数据库函数这些数据库程序逻辑代码编写场合使用，即把它看成是一个运算过程的中间工具而不要用其作数据的存储形式。

另外还有一个需要探讨的问题，那就是Date类型长度是7，而Char(8)或Char(14)要比之浪费不少的存储空间，其中这个问题在古代确实是一个大问题，那时候一间茅屋都要合理利用，现在很容易就可以得到广厦千万间。由于硬件性价比持续提升，也就可以使我们采用一些软件上更简便的方法来改善程序的设计，如Java的代码反射，IoC的实现注入，XML形式的数据表示都是受惠于硬件的提升。因此，现在，一般而言，很微小的存储空间占用和性能的影响并不需要设计人员特别的关注，他们要更多关注的往往是如何使逻辑简化，如何使系统更具扩展性，可维护性和移植性上。