5、在数据库移植上的比较 由于CHAR类型日期实际上是一个字符类型字段，字符类型是最基本的数据类型，在构造Insert ,Update,Delete，Selete的SQL时，各种数据库对字符类型字段的处理几乎一致，因此在数据库的移植上比较容易。
对于DATE类型的日期，由于不同数据库对日期的操作差异很大，如获取数据库的时间函数，Oracle为sysdate，SqlServer为getdate()，而MySql为now()；从Date字段中抽取年的数值，Oracle为extract(year from <date>)，SqlServer和MySql均为month(<date>)。由于日期函数在不同数据库差别巨大，带DATE类型日期字段的表在数据库的移植上就不如CHAR类型日期来得简单易行。
也许，有人会说现在都采用Hibernate进行映射ORM了，Hibernate已经屏蔽了具体数据库的不同，何来的数据库移植？这话在一定程度上是没有错的，但是Hibernate框架由于通过对象映射的方法产生SQL语句，有时往往很难获得最优的查询性能的SQL语句。所以，对于一些有性能要求较高的查询，往往采用直接编写SQL语句，或采用iBatis框架，后两者都需要直接使用SQL语句，此时数据库的移植问题就暴露出来了。
不但在数据库的移植问题上，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形式的数据表示都是受惠于硬件的提升。因此，现在，一般而言，很微小的存储空间占用和性能的影响并不需要设计人员特别的关注，他们要更多关注的往往是如何使逻辑简化，如何使系统更具扩展性，可维护性和移植性上。
