3、关于java.sql.Date与java.sql.Date

  java.sql.Date是为了配合SQLDATE而设置的数据类型。

  “规范化”的java.sql.Date只包含年月日信息,时分秒毫秒都会清零。格式类似:YYYY-MM-DD。

  当我们调用ResultSet的getDate()方法来获得返回值时,java程序会参照"规范"的java.sql.Date来格式化数据库中的数值。因此,如果数据库中存在的非规范化部分的信息将会被劫取。

  在sun提供的ResultSet.java中这样对getDate进行注释的:

  Retrieves the of the designated column in the current row of this <code>ResultSet</code> object as a “java.sql.Date” object in the Java programming language.

  如果我们把一个java.sql.Date值通过PrepareStatement的setDate方法存入数据库时,java程序会对传入的java.sql.Date规范化,非规范化的部分将会被劫取。然而,我们java.sql.Date一般由java.util.Date转换过来,如:java.sql.Date sqlDate=new java.sql.Date(new java.util.Date().getTime()).

  显然,这样转换过来的java.sql.Date往往不是一个规范的java.sql.Date.要保存java.util.Date的精确值,这个时候java.sql.Timestamp.算是一个比较好的选择。

  4、一刀切的做法

  关于这个做法曾经在我身边发生过一些小小的争议,有一个老师告诉我们在数据库中使用时间类型的时候统统设置为字符串类型,而另一个老师是在应用程序开发的告诉我们那样设计数据库表字段是不专业的做法。可是后发现如果在应用程序中将时间数据作为java.util.Date,而在数据库中时间数据字段类型为Date类型,那么在进行时间数据更新或者查询方面都将是上面一大堆的转化方式显的格外有意义。

  后来将这个问题想了想,为什么没有为关于这两个类型做一个适配器的东西类进行转换,这样不是更方便了。

  现在似乎明白了些。如果数据库中是时间字段的更新来自数据库服务器的操作,那么大可放心的使用数据库中的时间类型,而且从数据库中读出数据在应用程序中转换相当容易和自由;相反,如果数据库中的时间字段的更新来自外部应用程序,那么可以将数据库中的时间类型字段设计为字符串类型,因为对于数据库来讲它是服务于应用程序的,而且这样来自外部的时间格式将更容易控制和设置。

  5、可以一劳永逸

  粗略的想一下没有类似时间格式的转换是应为我们在实际应用中需要展现的时间格式显示是千变万化的,因此只能通过对特定的业务需求进行分析编写一个工具类来处理这些问题,当然这样的工作也是一劳永逸的。

  这里列一个处理:

    //获得当前时间,声明时间变量 
            Calendar calendar = Calendar.getInstance(); 
            //得到年 
            int year = calendar.get(Calendar.YEAR); 
            //得到月,但是,月份要加上1  
            int month = calendar.get(Calendar.MONTH) + 1; 
            //获得日期 
            int day = calendar.get(Calendar.DATE); 
            //字符串转换成日期时间格式 
            String today = "" + year + "-" + month + "-" + day + "";

  好了,时间不多了,一劳永逸是建立在高度的抽象再抽象,分析提取在分析的基础上的。