BlogJava-★yesjoy★-文章分类-数据库设计

浅析J2EE应用中的数据库中的时间值字段的数据类型（二）

★yesjoy★ — Fri, 13 Oct 2006 05:51:00 GMT

4、在数据统计上的比较

　　假设要根据EXPIRE_DATE字段，统计2005年每月到期的用户数。CHAR类型日期和DATE类型日期对应的统计SQL语句分别分析如下。

　　·CHAR类型日期

　　这种日期的表，要在日期字段上做统计是很方便的，下面的SQL语句统计出2005每月的T_USER记录：

select substr(EXPIRE_DATE,5,2) MONTH,count(USER_ID) from T_USER where EXPIRE_DATE like '2005%'group by substr(EXPIRE_DATE,5,2)

　　　表 5 CHAR类型日期统计SQL

　　其中substr(EXPIRE_DATE,5,2)字符串处理函数获取日期的月份，如"20060102"通过该函数即得到"01"的月份值。而"EXPIRE_DATE like '2005%'"的条件式即过滤出所有2005年的数据，并且可以使用EXPIRE_DATE字段上的索引。

　　·DATE类型日期

　　对于DATE类型日期按月进行统计，乍一看，可以采用和CHAR类型日期相似的统计SQL语句：

select extract(month from EXPIRE_DATE) MONTH,count(USER_ID) from T_USER where extract(year from EXPIRE_DATE ) = 2005 group by extract(month from EXPIRE_DATE)

　　　　表 6 DATE类型日期统计SQL(全表扫描)

　　注：在Oracle中通过extract(<日期域名> from Date)函数获取日期的某特定日期域仁值。

　　但是仔细一分析，就会发现由于where条件式中对索引字段EXPIRE_DATE使用了extract()函数，因此EXPIRE_DATE上的索引在此统计SQL中将无法使用，所以该统计将引发一个全表扫描。
当然，你可以在EXPIRE_DATE字段上建立函数索引，但EXPIRE_DATE上的查询可以不仅仅只会用到extract()函数，一一为这些EXPIRE_DATE字段建立多个函数索引不但麻烦而且会影响T_USER上数据更新操作的性能。

　　当然，除了上式的统计方法外，还可以采用另外一种方法：

select extract(month from EXPIRE_DATE) month,count(USER_ID) from T_USER where EXPIRE_DATE between to_date('20050101','yyyymmdd') and to_date('20051231','yyyymmdd') group by extract(month from EXPIRE_DATE)

　　　　表 7 DATE类型日期统计SQL(使用索引)

　　表 7的方法可以使用EXPIRE_DATE字段上的索引，但又引入了一个我们前面已经提到过的不可避免的问题：必须按日期语义构造出开始和结束日期，以形成一个日期区间。在该例中，由于是对一整年进行统计，因而开始结束日期容易获得，如果是精确到月的日期区间，则需要计算出某月的最后一天，程序就复杂多了。但如果是CHAR类型日期的表，构造统计SQL语句，也易如反掌：如我们要统计200304～200402每月到期的用户数，可以通过以下SQL语句：

select substr(EXPIRE_DATE,1,6) year_month ,count(USER_ID)from T_USER where EXPIRE_DATE between '20030400' and '20040299'group by substr(EXPIRE_DATE,1,6)

　　即将开始日期以0补齐到8位,将结束日期以9补齐到8位。

　5、在数据库移植上的比较

　　由于CHAR类型日期实际上是一个字符类型字段，字符类型是最基本的数据类型，在构造Insert ,Update,Delete，Selete的SQL时，各种数据库对字符类型字段的处理几乎一致，因此在数据库的移植上比较容易。

　　对于DATE类型的日期，由于不同数据库对日期的操作差异很大，如获取数据库的时间函数，Oracle为sysdate，SqlServer为getdate()，而MySql为now()；从Date字段中抽取年的数值，Oracle为extract(year from )，SqlServer和MySql均为month()。由于日期函数在不同数据库差别巨大，带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形式的数据表示都是受惠于硬件的提升。因此，现在，一般而言，很微小的存储空间占用和性能的影响并不需要设计人员特别的关注，他们要更多关注的往往是如何使逻辑简化，如何使系统更具扩展性，可维护性和移植性上

★yesjoy★ 2006-10-13 13:51 发表评论

浅析J2EE应用中的数据库中的时间值字段的数据类型（一）

★yesjoy★ — Fri, 13 Oct 2006 05:45:00 GMT

作者：陈雄华

　　概述

　　在设计库表时，经常会碰到用于保存"时间值"的字段，如create_date，begin_time，login_time等，举不胜举。针对这些类型的字段，在设置数据类型时，有一个有趣的现象，即其中一些人使用Date类型，而另外一些人使用Char(8)/Char(14)类型。一般而言，初学者，在校学生，甚至老师一般都属于前者，他们一个鲜明的特征是对数据库的理论掌握很好，但普遍缺少实际项目的开发经验；而后者一般是那些有一定项目经验的开发人员。乍一看，这些时间值字段，用Date类型应该是合情合理，天经地义的，为什么有一定项目经验的人偏偏要这样"弃暗投明"，这样"特立独行"呢？

　　这是典型的白猫黑猫问题，理论化的东西很光鲜，但有时在实践中就是不灵光，而一些"旁门左道"的东西却显得更加方便易用。本文将通过一个具体例子的不同开发过程，分析Char类型时间字段为什么在实践中更受欢迎。考虑到篇幅所限，我们仅对Date类型和Char(8)类型的时间值字段作比较分析，对于Date类型和Char(14)类型的分析，相信大家完全可以由此而及彼。

　　1、比较的例子

　　我们设计了一个具体的实例，对用Char类型和Date类型的日期进行比较分析，使用的是Oracle数据库，现对该实例进行简单的描述。

　　假设有一个T_USER表，有一个EXPIRE_DATE（过期日期）字段，要求记录年、月、日的日期数据，对EXPIRE_DATE字段分别采用两种实现方式：

图 1 T_USER表

　　左边的T_USER(1)使用CHAR(8)保存日期值，以yyyymmdd格式保存，如20070606，20070501；而右边的T_USER(2)使用Date数据类型，我们称左边的数据表设计为CHAR类型日期方案，而右边的设计为DATE类型日期方案。

　　表中的数据当然不会生而有之，我们假设从Web的表单上提交上来，保存到表中，当然还要有查询、统计等操作，我们就通过这些常见的数据操作分析这两个方案的不同，通过这样的分析，孰劣孰优，相信我们就可以进行很好的判断了。

2、从表单添加记录的比较

　　Struts+Spring+Hibernate是目前Web项目中流行的框架，在这个框架中，Hibernate需要为T_USER生成一个User.java的PO，CHAR类型日期方案的User.expireDate为String类型，而DATE类型日期方案的User.expireDate为java.sql.Date类型，如图 2所示：

图 2 两方案分别对应的User.java PO

　　而对应Struts的展现层，需要提供一个UserActionForm，以获取页面表单的提交数据。不管采用哪种日期方案，UserActionForm.expireDate属性类型均为String，因为这样一来，可以直接从Struts的获取数据，另外也方便数据回显到页面中；如果UserActionForm.expireDate采用java.sql.Date类型，则标签的数据将无法正确地填充UserActionForm.expireDate对象属性中。

图 3 UserActionForm.java

　　表单提交上来的expireDate是带时间格式的字符串，如2006-06-06，2001-10-12，UserActionForm.expireDate简单地接受该值，在UserAction中，必须用UserActionForm的数据生成持久层所需的PO，即User对象。两种日期方案在数据的转换逻辑的区别分别描述如下：

　　·CHAR类型日期

　　由于User.expireDate也是String类型，因此，仅需要将UserActionForm.expireDate属性完全拷贝到User中，然后再将User.expireDate属性的日期格式符"-"去除却可，却将2006-06-06转换为20060606，对应操作逻辑的主要代码如下：

1. User user = new User();
2. //将userActionForm中的数据拷贝到user对象中
3. BeanUtils.copyProperties(user, userActionForm);
4. //将日期格式符去除，得到数据库存储日期格式，如将2006-06-06转换为20060606
5. user.setExpireDate(user.getExpireDate().replace("-",""));
6. …
7. //调用服务对象，将user保存到T_USER中
8. userService.save(user);

　　·DATE类型日期
在DATE类型日期方案中，由于PO User.expireDate属性为java.sql.Date，和UserActionForm.expireDate 存在类型的不匹配，因此需要通过一个转换函数，将String日期转换为java.sql.Date的日期。其主要代码如下：

1. User user = new User();
2. //由于expireDate不能直接进行拷贝，因此需要逐一拷贝属性
3. BeanUtils.copyPropertie(user, userActionForm,"userId");
4. BeanUtils.copyPropertie(user, userActionForm,"userName");
5. //使用转换函数str2Date()将String类型的时间转换为java.sql.Date的时间
6. java.sql.Date expireDate = str2Date(userActionForm.getExpireDate());
7. //设置expireDate属性
8. user.setExpireDate(expireDate);
9. …
10. //调用服务对象，将user保存到T_USER中
11. userService.save(user);

　　通过上面的比较，可以看出，使用DATE时间方案比使用CHAR时间方案在添加数据的处理上要复杂一些，表现在：

　　1) 由于属性名相同而类型存在不可直接转换的问题将导致无法进行对象间属性批量拷贝，即BeanUtils. copyProperties()批量属性拷贝函数会抛出异常，因此只能手工逐一进行单个具体属性的拷贝，如果属性个数很多，这一机械式的属性拷贝代码块就要相应增大，不但使代码显示臃肿难看，而且直接降低了代码的可维护性，因为一但因表字段名改变，就需要手工调整这段代码。

　　2) 需要提供一个将String日期串转换为java.sql.Date的转换函数，将年、月、日时间域分别从字串中抽取出来，并转换为int类型，然后利用java.sql.Date(int year,int month,int date)构造函数得到对应的java.sql.Date对象。

3、在数据查询上的比较

　　假设需要以EXPIRE_DATE字段为条件查询T_USER的记录，由于已经在T_USER.EXPIRE_DATE字段上建立了索引，在查询时需要考虑使用该索引。Web的查询界面如下：

图 4 查询界面

　　日期条件值可以是yyyy、yyyy-mm、yyyy-mm-dd的格式，假如开始日期为2001，结束日期为2002，则表示日期区间为2001-01-01到2002-12-31，如果开始日期为2001，结束日期为2002-02，则表示日期区别为2001-01-01到2002-02-28，以此类推。此外，如果开始日期条件未提供，表示查询所有小于等于结束日期的记录，反之如果结束日期条件未提供，表示查询所有大于等于开始日期的记录。

　　·CHAR类型日期

　　CHAR类型日期数据表保存的是CHAR(8)类型的日期，此时可以用简单的方法构造出查询语义丰富，语句结构统一的查询SQL语句，构造方法如下：

　　1) 去除格式符：将开始，结束查询日期值中的时间格式符去除。

　　2) 补尾串：将开始日期字符串末尾用0补齐到8位长度，将结束日期字符串末尾用9补齐到8位长度。特别的，如果开始日期为空，则用00000000代替，而结束日期未提供则用99999999代替。

　　3) 构造查询SQL：用以下SQL语句构造查询语句：

select * from T_USER where EXPIRE_DATE between <开始日期> and <结束日期>

　　表 1 CHAR类型日期查询SQL结构

　　举个例子：假如开始，结束日期值分别为2001、2002-02，则按以上三步的处理过程分别为：

　　1)去除格式符：2001，200202

　　2)补尾串：20010000，20020299

　　3)构造查询SQL：

select * from T_USER where EXPIRE_DATE between '20010000'and '20020299'

　　又如开始日期为空，结束日期为200203，则对应的查询SQL为：

select * from T_USER where EXPIRE_DATE between '00000000'and '20020399'

　　·DATE类型日期

　　由于DATE类型日期在数据库表中对应的是Date类型字段，首先，我们不能仿照CHAR类型日期的查询SQL结构构造如下的查询SQL：
select * from T_USER where to_char(EXPIRE_DATE,'yyyymmdd') between <开始日期> and <结束日期>
因为在EXPIRE_DATE上建立了索引，如果在EXPIRE_DATE施加了to_char()的数据库函数，就无法使用该索引，将引发一个全表描述。
所以，还得将开始、结束日期字符串用to_date()数据库函数转换为Date类型，如：

select * from T_USER where EXPIRE_DATE between to_date(<开始日期>,'yyyymmdd') and to_date(<结束日期>,'yyyymmdd')

　　表 2 CHAR类型日期查询SQL结构

　　但由于使用了to_date字符串日期转换函数，就必须保证开始日期和结束日期的字符串必须是语义合法日期字符串，如20010101,20020228，如果是语义错误的日期字符串，如20010000,20020299，to_date函数将发生转换错误，致使上面的查询SQL语句运行错误。因此，只有开始日期和结束日期字符串都合法时，才可以使用上式的查询SQL。

　　如果开始或结束日期未精确到日，即只精通到年或月，如2001,200202，则在应用程序的服务层，必须对日期串进行语义分析，将其补齐到8位合法日期字符串，如开始日期字符串"2001"就必须补齐为"20010101"，而结束日期字符串"200202"就必须先补齐为"20020228"（非润年的平月），而这一转换逻辑处理起来是比较费神费力的，一不小心就可能引入一个Bug。

　　第二个麻烦的问题是，如果开始日期和结束日期为空，SQL语句又该如何构造呢？如果还按照表 2的SQL结构进行构造，那么就必须回答一个问题：最小开始日期和最大的结束日期分别是多少，因为你不能用"00000000"来代表最小的日期，也不能用"99999999"来代表最大的日期。

　　为了避免回答这个问题，就需要在开始日期和结束日期为空时分别采用不同结构的查询SQL语句：

select * from T_USER where EXPIRE_DATE >= to_date(<开始日期>,'yyyymmdd')

　　　表 3 结束日期条件值为空时

select * from T_USER where EXPIRE_DATE <= to_date(<结束日期>,'yyyymmdd')

　　　表 4 开始日期条件值为空时

　　综上所述，为了使用在EXPIRE_DATE字段上的索引，DATE类型日期在构造查询SQL上明显比CHAR类型日期复杂，具体表现在以下两点：

　　1) 需要对日期条件值进行语义分析，以得到精确到日的语义合法的日期字符串。

　　2) 需要为开始/结束日期条件值均不为空，开始日期条件值为空，结束日期条件值为空三种情况分别构造不同结构的SQL语句，也构造SQL的程序必须对应一个分支

★yesjoy★ 2006-10-13 13:45 发表评论

级联删除问题总结

★yesjoy★ — Mon, 09 Oct 2006 05:39:00 GMT

				
						
								
										

										
												
												SQL
												>
												 
												create
												 
												table
												 t (id 
												number
												 
												primary
												 
												key
												);
 表已创建。
 SQL
												>
												 
												create
												 
												table
												 t1 (id 
												number
												, tid 
												number
												, 
												constraint
												 fk_t1_t_id 
												foreign
												 
												key
												 (tid)
  
												 
												references
												 t (id)); 表已创建。
 SQL
												>
												 
												insert
												 
												into
												 t 
												values
												 (
												1
												);
 已创建 
												1
												 行。
 SQL
												>
												 
												insert
												 
												into
												 t1 
												values
												 (
												1
												, 
												1
												);
 已创建 
												1
												 行。
 SQL
												>
												 
												commit
												;
 提交完成。
 SQL
												>
												 
												delete
												 t;

												delete
												 t
												*
												ERROR 位于第 
												1
												 行:ORA
												-
												02292
												: 违反完整约束条件 (YANGTK.FK_T1_T_ID) 
												-
												 已找到子记录日志
SQL
												>
												 
												alter
												 
												table
												 t1 
												drop
												 
												constraint
												 fk_t1_t_id; 表已更改。
 SQL
												>
												 
												alter
												 
												table
												 t1 
												add
												 
												constraint
												 fk_t1_t_id 
												foreign
												 
												key
												 (tid) 
												references
												 t (id) 
												on
												 
												delete
												 
												cascade
												;

表已更改。 SQL
												>
												 
												delete
												 t;
 已删除 
												1
												 行。
 SQL
												>
												 
												select
												 
												*
												 
												from
												 t;
 未选定行
 SQL
												>
												 
												select
												 
												*
												 
												from
												 t1;
 未选定行
 SQL
												>
												
														

														
												
										
								
						
						
								
								drop
								 
								table
								 T_ES_Equipment 
								cascade
								 constraints;

								drop
								 
								table
								 T_ES_AnalysisTestCenter 
								cascade
								 constraints;

								create
								 
								table
								 T_ES_AnalysisTestCenter (
    id 
								varchar2
								(
								32
								) 
								not
								 
								null
								,
    brief_introduction 
								varchar2
								(
								255
								),
    analysis_test_center_name 
								varchar2
								(
								50
								),
    remark 
								varchar2
								(
								255
								),
    
								primary
								 
								key
								 (id)
);

								create
								 
								table
								 T_ES_Equipment (
    id 
								varchar2
								(
								32
								) 
								not
								 
								null
								,
    school_id 
								varchar2
								(
								255
								),
    upload_time date,
    equip_id 
								varchar2
								(
								50
								),
    accessories 
								varchar2
								(
								3255
								),
    alias 
								varchar2
								(
								50
								),
    application 
								varchar2
								(
								3255
								),
    certificate 
								varchar2
								(
								50
								),
    CHNNAME 
								varchar2
								(
								100
								),
    classification 
								varchar2
								(
								50
								),
    ENGNAME 
								varchar2
								(
								100
								),
    analysis_test_center_id 
								varchar2
								(
								32
								),
    
								primary
								 
								key
								 (id)
);

								alter
								 
								table
								 T_ES_Equipment 
    
								add
								 
								constraint
								 FK57481928D651B652 
    
								foreign
								 
								key
								 (analysis_test_center_id) 
    
								references
								 T_ES_AnalysisTestCenter;

★yesjoy★ 2006-10-09 13:39 发表评论

数据库设计规范总结

★yesjoy★ — Mon, 24 Apr 2006 14:49:00 GMT

设计元素	要求和说明
数据库标题	Ø 上线时创建的数据库使用中文，简要说明该数据库的用途，如文档对象管理等 Ø 开发过程中数据库名称应使用模板名称（现阶段涉及流程定义的数据库除外）
数据库文件名	Ø 使用汉语拼音或者英文单词作为文件名。如 shouwen.nsf 、 fawen.nsf 、 reportdemo.mdb 、 cfte.mdf 、 objectman.mdf 、 addressbook.mdf 等，基本原则是简单易懂，不能过长，建议使用拼音或者拼音缩写 Ø 对于分层次的数据库，如在讨论区下面分公司讨论区、产品讨论区的情况，应当在类别目录下，分别使用“类别名称 _ 分类名称 .mdf ”来建立数据库，对于讨论区的例子，就应当为 bbs 目录下： bbs_gongsi.mdf 等；或者使用 bbs_UNID.mdf ， UNID 是与此数据库关联的文档 UNID Ø 一律使用小写
数据库模板名称	按照版本控制规则，所有的数据库均应作为模板，在安装和升级时进行设计更新数据库模板名称形如： objectman 文档对象管理 R2.10 数据库模板名称使用项目简称加上数据库标题，然后加入基础版本信息，通常在数据库作了重大需求修改时才修改项目版本号
数据库涉及字符规范	采用 26 个英文字母（区分大小写）和 0~9 这十个自然数，加上下划线 _ 组成，共 63 个字符。不能出现其他字符（注释除外）
数据库表名称	数据库表名由前缀和实际名字组成。前缀使用小写字母 tb ，代表“表”。实际名字中，一个系统尽量采取同一单词，多个后面加 _ 来连接区分。因此，类似合法的表名 tbMember 、 tbMember_Info 、 tbForum_Board 、 tbBlog_Comment1
数据库表字段名称	字段由表的简称、实际名字组成。如果此字段关联另外的字段，那么加下划线 _ 连接关联表字段的字段名。因此，类似合法的字段名如 UserID_MeID 、 UserName 、 UserRegDate
视图名称	字段由前缀和实际名字组成，中间用下划线连接。前缀使用小写字母 vi ，表示视图。因此，类似合法的视图名如 vi_User 、 vi_UserInfo
存储过程名称	字段由前缀和实际名字加操作名字组成，中间用下划线连接。前缀使用小写字母 sp ，表示存储过程。操作名字如： Insert 、 Delelte 、 Update 、 Caculate 、 Confir 。例如： sp_User_Insert
sql 语句规范	所有 sql 关键词全部大写，比如 SELECT 、 UPDATE 、 FROM 、 ORDER BY 等
“关于数据库”文档	每个数据库都必须写“关于数据库”文档，它在版本控制中起到重要作用。“关于数据库”文档中应依次包含以下内容： Ø 数据库的名称当前版本号，形如： objectman 文档对象管理 R2.10.1 b060421 debug 它比模板信息增加了小版本号和构造日期，可以根据需要加入其他的简短英文备注，比如 debug 、 demo 。 debug 版包含大量调试信息，在发布前需要去除 demo 版仅用于演示 Ø 功能简介 Ø 数据库版本修订记录随版本更新，应包括主要小版本号、修订时间、修订人、修订情况简单概述。只包含当前大版本的信息，包括大版本继承的版本信息，再之前的信息不要保留此处修改内容指特性、 bug 的修改，设计元素的修改用单独的配套文档来记录 Ø 版权信息和开发者信息 Ø “关于”文档可以在数据库设计手册帮助中查看
“使用数据库”文档	每个数据库都应该有“使用数据库”文档，“使用数据库”文档的内容包括数据库的简单操作要点
数据库分类	一般为项目名称，如有必要可以将当前版本号写到该属性中

★yesjoy★ 2006-04-24 22:49 发表评论