浅析J2EE应用中的时间值字段的数据类
2007-12-23 12:36:55 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佺粯鍔﹂崜娆撳礉閵堝洨纾界€广儱鎷戦煬顒傗偓娈垮枛椤兘骞冮姀銈呯閻忓繑鐗楃€氫粙姊虹拠鏌ュ弰婵炰匠鍕彾濠电姴浼i敐澶樻晩闁告挆鍜冪床闂備胶绮崝锕傚礈濞嗘挸绀夐柕鍫濇川绾剧晫鈧箍鍎遍幏鎴︾叕椤掑倵鍋撳▓鍨灈妞ゎ厾鍏橀獮鍐閵堝懐顦ч柣蹇撶箲閻楁鈧矮绮欏铏规嫚閺屻儱寮板┑鐐板尃閸曨厾褰炬繝鐢靛Т娴硷綁鏁愭径妯绘櫓闂佸憡鎸嗛崪鍐簥闂傚倷鑳剁划顖炲礉閿曞倸绀堟繛鍡樻尭缁€澶愭煏閸繃宸濈痪鍓ф櫕閳ь剙绠嶉崕閬嶅箯閹达妇鍙曟い鎺戝€甸崑鎾斥枔閸喗鐏堝銈庡幘閸忔﹢鐛崘顔碱潊闁靛牆鎳愰ˇ褔鏌h箛鎾剁闁绘顨堥埀顒佺煯缁瑥顫忛搹瑙勫珰闁哄被鍎卞鏉库攽閻愭澘灏冮柛鏇ㄥ幘瑜扮偓绻濋悽闈浶㈠ù纭风秮閺佹劖寰勫Ο缁樻珦闂備礁鎲¢幐鍡涘椽閸愵亜绨ラ梻鍌氬€峰ù鍥敋閺嶎厼鍨傞幖娣妼缁€鍐煥濠靛棙顥滈柣锕備憾濮婂宕掑▎鎺戝帯濡炪們鍨归敃銈夊煝瀹ュ鍗抽柕蹇曞Х椤斿姊洪幖鐐插姶闁告挻鐟╅幃姗€骞庨懞銉у幐闂佸憡鍔戦崝搴㈡櫠閺囩姷纾奸柍褜鍓熷畷姗€鍩炴径鍝ョ泿闂傚⿴鍋勫ú銈吤归悜鍓垮洭鏁冮埀顒勬箒濠电姴锕ら悧蹇涙偩濞差亝鐓涢悘鐐额嚙婵″ジ鏌嶇憴鍕伌鐎规洖宕埢搴ょ疀閹惧妲楃紓鍌氬€搁崐鐑芥⒔瀹ュ绀夐幖杈剧到閸ㄦ繃銇勯弽顐粶濡楀懘姊洪崨濠冨闁搞劍澹嗙划濠氬箮閼恒儱鈧敻鏌ㄥ┑鍡欏嚬缂併劏妫勯湁闁绘ǹ宕甸悾鐑樻叏婵犲啯銇濇俊顐㈠暙閳藉鈻庨幇顓炩偓鐑芥⒑鐠囨彃顒㈤柣顓у櫍瀹曪繝骞庨懞銉ヤ粧濡炪倖娲嶉崑鎾垛偓瑙勬礀閻栧ジ銆佸Δ浣哥窞閻庯綆鍋呴悵顐⑩攽閻樻剚鍟忛柛锝庡灣瀵板﹪宕滆閸嬫挾绮☉妯绘悙缂佺姵鐓¢弻娑㈠Ψ椤旂厧顫╅梺钘夊暟閸犳牠寮婚敐澶婃闁圭ǹ瀛╅崰鎰版⒑閼姐倕鏋庣紓宥咃躬瀵鈽夐埗鈹惧亾閿曞倸绠f繝闈涙川娴滎亝淇婇悙顏勨偓銈夊礈濞嗘挻鍋嬮柛鈩冪▓閳ь剚妫冨畷姗€顢欓崲澹洤绠圭紒顔煎帨閸嬫捇鎳犻鈧崵顒傜磽閸屾艾鈧娆㈤敓鐘茬獥婵°倕鎳庣粻浼存煙闂傚鍔嶉柛瀣ф櫊閺岋綁骞嬮敐鍡╂缂佺虎鍘搁崑鎾绘⒒娴h櫣甯涢柛鏃€娲滅划鏃堟濞磋櫕鐩畷姗€顢欓崗鍏夹氶梻渚€鈧偛鑻晶顖炴煏閸パ冾伃妤犵偞甯¢獮瀣攽閹邦亞纾婚梺璇叉唉椤骞愭搴g焼濞撴埃鍋撻柛鈺冨仱楠炲鏁傞挊澶夋睏闂備礁婀辩划顖滄暜閳哄倸顕遍柍褜鍓涚槐鎾存媴閻熸澘濮㈤悷婊勫閸嬬喖宕氶幒鎴旀瀻闁规儳鐤囬幗鏇炩攽閻愭潙鐏﹂柣顓у枛閳讳粙顢旈崼鐔哄幍闁荤喐鐟ョ€氼剚鎱ㄩ崶銊d簻闁靛濡囩粻鐐存叏婵犲啯銇濋柡灞芥嚇閹瑩鎳犵捄渚純濠电姭鎷冮崒姘ギ闂佸搫鐬奸崰鏍箹瑜版帩鏁冮柨婵嗘噽閿涙捇姊绘担鐟邦嚋缂佽瀚板畷鎴濃槈閵忕姷鍘撮梺鐟邦嚟婵參宕戦幘缁樻櫜閹煎瓨锚娴滅偓銇勯幘瀵糕姇婵炲懎锕弻锛勪沪閻e睗锝嗙箾绾板彉閭鐐茬箳娴狅箓鎸婃径濠呭帿闂傚倸鍊烽悞锕傛儑瑜版帒纾归柡鍥ュ灩缁犵娀鏌熼柇锕€鏋熸い顐f礋閺岀喖骞嗚閹界姴鈹戦娑欏唉闁哄本鐩獮姗€寮堕幋鐘点偡闂備礁鎲¢幐绋跨暦椤掑嫧鈧棃宕橀鍢壯囨煕閳╁喚娈樺ù鐘虫倐濮婃椽鎳¢妶鍛瘣闂佸搫鎳忛惄顖炲箖妤e啯鍊婚柦妯猴級閵娧勫枑濠㈣埖鍔曠壕濠氭煙閸撗呭笡闁哄懏鐓¢獮鏍垝閻熸澘鈷夐梺璇茬箰缁夌懓顫忛搹鍦<婵☆垵顕ч棄宥呪攽閻愭彃绾ч柨鏇樺灪娣囧﹪鎮界粙璺槹濡炪倖鐗楀銊╂偪閳ь剟姊婚崒姘偓鎼佹偋婵犲嫮鐭欓柟閭﹀枦婵娊鏌ゅù瀣珖缁炬崘妫勯湁闁挎繂鐗婇ˉ澶愭煟閹炬潙濮堥柟渚垮妼铻g紒瀣仢椤鈹戦垾鍐茬骇闁告梹鐟╅悰顔嘉熼崗鐓庣彴闂佽偐鈷堥崜锕€危娴煎瓨鈷掑ù锝嚽归弳閬嶆煙绾板崬浜扮€规洘鍔栫换婵喰掔粙鎸庡枠鐎殿喛鍩栭幆鏃堝箻鐎涙ɑ婢戝┑锛勫亼閸婃牕顫忔繝姘ラ悗锝庝憾閸熷懘鏌曟径娑滅濞存粍绮嶉妵鍕箻鐠鸿桨绮跺┑鈩冨絻椤兘寮婚敐澶嬫櫜闁搞儜鍐ㄧ婵°倗濮烽崑鐐垫暜閿熺姷宓侀悗锝庡枛缁秹鏌嶈閸撶喖骞冨Δ浣虹瘈婵﹩鍘搁幏娲煟閻斿摜鎳冮悗姘煎弮瀹曟洖螖閸涱喚鍘卞┑鈽嗗灥閵嗏偓闁稿鎹囬幃銏ゅ箵閹烘垹闃€婵犵數濮烽弫鍛婃叏閻戣棄鏋侀柛娑橈攻閸欏繘鏌i幋锝嗩棄闁哄绶氶弻娑樷槈濮楀牊鏁鹃梺鍛婄懃缁绘垿濡甸崟顖氱闁告鍋熸禒鑲╃磼閻愵剙鍔ゆい顓犲厴瀵鎮㈤悡搴n槶閻熸粌绻掗弫顔尖槈閵忥紕鍘撻梻浣哥仢椤戝懘鎮橀敃鍌涚厪闁搞儜鍐句純濡ょ姷鍋炵敮鈥崇暦閸楃儐娓婚柟顖嗗本顥$紓鍌氬€搁崐鎼佸磹妞嬪海鐭嗗〒姘e亾閽樻繈姊洪鈧粔鎾几娴g硶鏀介柣妯挎珪閻ㄦ垹鈧鎸风欢姘跺蓟濞戙垹鐒洪柛鎰典簴婵洭姊虹粙鍖″姛闁稿繑锕㈠璇测槈濡攱鏂€闂佺硶鍓濋〃蹇斿閳ь剚淇婇悙顏勨偓鏍ь潖瑜版帒绀夐柡鍥ュ灩閻撴﹢鏌熸潏楣冩闁稿﹤顭烽弻娑㈠Ψ閵忊剝鐝栭柡宥忕節濮婄粯鎷呴崨濠傛殘闂佸湱枪椤兘骞冮悜鑺ユ櫆闁伙絽澶囬弨铏節閻㈤潧孝婵炶绠撳畷鐢稿礃椤旂晫鍘撻梺鍛婄箓鐎氼剟寮抽悢鍏肩叆婵炴垶鐟ч惌鎺撴叏婵犲洨绱伴柕鍥ㄥ姍楠炴帡骞嬪⿰鍐╃€抽梻鍌欑閹诧繝鎮烽妷锔绘闁归棿绀侀悡婵嬫煙閻愵剚鐏遍柛顐邯閺屾盯顢曢妶鍛亖闂佸憡蓱閹倿寮婚敐鍫㈢杸闁哄洨鍋橀幋椋庣磼缂併垹骞栭柣鏍帶閻g兘骞嬮敃鈧粻濠氭偣閸ヮ亜鐨洪柣銈傚亾婵犵數鍋犻幓顏嗗緤娴犲绠熼柨鐔哄Т绾捐銇勯弽顐沪闁抽攱鍨归惀顏堫敇閻愭潙娅f繛瀛樼矊缂嶅﹪骞冪捄琛℃闁哄诞鍐ㄐ曢梻浣虹《閺備線宕戦幘鎰佹富闁靛牆妫楃粭鎺楁煕閻曚礁浜伴柟顖氬暙鐓ゆい蹇撴噽閸樺憡绻涙潏鍓у埌婵犫偓鏉堛劍娅犳い蹇撶墛閻撳啴鎮峰▎蹇擃仼闁诲繑鎸抽弻鐔碱敊閻e本鍣伴悗娈垮枛閻栧ジ鐛€n喗鍋愰弶鍫厛閺佸洭姊婚崒姘偓椋庣矆娴i潻鑰块弶鍫涘妿娴犳岸姊绘担渚敯濠殿喓鍊楅崚鎺撴償閵娿儳顦梺鍦劋椤ㄥ懐鐚惧澶嬬厱妞ゆ劑鍊曢弸搴∶归悩鐑橆仩缂佽鲸鎸婚幏鍛村礈閹绘帒澹嶆俊鐐€栧ú妯荤箾婵犲洤鏋侀柛鎰靛枛绾惧吋绻涢幋鐐跺妤犵偛鐗撳缁樻媴閸涘﹥鍎撳┑鐐茬湴閸ㄨ棄鐣峰┑鍡欐殕闁告洦鍓欓埀顒€鐖奸弻锝呂熼懖鈺佺闂佺粯鎸诲ú鐔煎蓟閻斿吋鍤嬫い鎺嗗亾濠碉紕鍘ч湁婵犲﹤瀚崝銈夋煃鐟欏嫬鐏撮柡浣哥Ч瀹曠喖顢曢埄鍐╃窔闂傚倷鑳舵灙闁挎洏鍎甸幃褔鎮╅懠顒佹濠电娀娼ч鍡涘疾濠靛鐓冪憸婊堝礈閻旂厧鐏抽柨鏇炲€搁柨銈嗕繆閵堝倸浜鹃梺缁樺笒閻忔岸濡甸崟顖氱鐎广儱鐗嗛崢锛勭磽娴e搫孝濠⒀傜矙閸┾偓妞ゆ巻鍋撻柛妯荤矒瀹曟垿骞橀弬銉︽杸闂佺粯枪娴滎剛绮i弮鍫熺厱閻庯綆鍋掑▓鏃堟煃鐟欏嫬鐏存い銏$懅濞戠敻鎮滈悾灞藉冀濠电姷鏁搁崑娑㈠箯閹寸姴绶ら柛顭戝暎閿濆绠涢柡澶庢硶椤斿﹪姊洪悷鏉挎毐缁剧虎鍙冨畷浼村箻鐠囪尙顔嗛梺缁樶缚缁垶宕甸幋锔界厾缂佸娉曟禒娑欐叏閿濆棗濮嶆慨濠傤煼瀹曟帒顫濋钘変壕闁绘垼濮ら崵鍕煠閸濄儲鏆╁ù鐘崇缁绘繈鎮介棃娑楃捕濡炪倖娲﹂崣鍐ㄧ暦濡も偓铻e〒姘煎灠濞堛劌顪冮妶鍡楀闁稿﹥鐗滈埀顒佺濮樸劑鍩€椤掑倹鍤€濠㈢懓锕畷浼村冀瑜夐弸鏃堟煏婵犲繐顩紒鈾€鍋撻梻浣圭湽閸ㄨ棄岣胯閻楀海绱撴担鍝勪壕婵犮垺岣跨划鏃堟偡闁箑娈ㄩ梺鍝勮閸庤京绮婚悽鍛婄厵闁绘垶岣跨粻姗€鏌涢悙鍨毈闁哄矉缍侀幃鈺呮倻濮楀棔鍝楅梺璇茬箰缁诲牓宕濆畝鍕垫晩闊洦绋戝敮閻熸粌顦靛畷鎴﹀箻閼搁潧鏋傞梺鍛婃处閸撴瑧鍠婂鍛斀闁宠棄妫楁禍婵堢磼鐠囨彃鈧潡鏁愰悙鍓佺杸婵炴垶鐟﹂崕顏堟⒑闂堚晛鐦滈柛姗€绠栭弫宥呪堪閸愶絾鏂€闂佸疇妫勫Λ妤呮倶閻樼粯鐓欑痪鏉垮船娴滀即鏌ㄥ┑鍫濅粶妞ゆ挸銈稿畷鍫曞煛閸愯法闂繝鐢靛仩閹活亞绱炴笟鈧棢闁规崘顕х粈澶屸偓骞垮劚椤︿即鎮″▎鎴犵<閻庯綆浜炴禒銏ゆ煛閸℃稐鎲鹃柡宀嬬秮閺佹劙宕惰楠炲螖閻橀潧浠滄い鎴濐樀瀵偊宕橀鑲╁姦濡炪倖甯掗崐缁樼▔瀹ュ應鏀介柣妯虹-椤f煡鏌涚€e墎绉柡灞剧洴婵$兘骞嬪┑鍡樻婵°倗濮村ú顓㈠箖濡ゅ啯鍠嗛柛鏇ㄥ墮绾板秶绱撴担鍓叉Ч闁瑰憡濞婇崹楣冨籍閸繄顦ㄥ銈嗘煥濡插牐顦归柡灞剧洴閸╁嫰宕楅悪鈧禍顏勎涢崟顐悑闁搞儮鏅濋敍婵囩箾鏉堝墽鍒板鐟帮躬瀹曟洟骞囬悧鍫㈠幈闂侀潧枪閸庨亶銆傚畷鍥╃<妞ゆ梻鈷堥崕蹇斻亜閹惧啿鎮戠€垫澘瀚埀顒婄秵娴滄牠宕戦幘缁樼叆閻庯絻鍔嬬花濠氭⒑閻熺増鎯堢紒澶婄埣钘濋柨鏃堟暜閸嬫挸鈻撻崹顔界亪闂佽绻戠换鍫ュ春閻愬搫绠i柨鏇楀亾闁绘搫绻濋弻娑㈠焺閸愮偓鐣兼繛瀵稿閸ㄨ泛顫忓ú顏勫窛濠电姴娴烽崝鍫曟⒑閸涘﹥澶勯柛娆忛鐓ら柛娑橈梗缁诲棝鏌曢崼婵堢闁告帊鍗抽弻娑㈡偆娴e摜浠搁悗瑙勬礃閸旀瑥鐣疯ぐ鎺濇晝闁挎繂鎳庢导搴㈢節绾版ɑ顫婇柛銊﹀▕瀹曘垼顦崇紒鍌氱У閵堬綁宕橀埡浣插亾閸偅鍙忔俊顖滃帶娴滈箖鎮楀鐐

概述
在设计库表时,经常会碰到用于保存"时间值"的字段,如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的<Html:text property="expireDate"/>获取数据,另外也方便数据回显到页面中;如果UserActionForm.expireDate采用java.sql.Date类型,则<html:text property="expireDate"/>标签的数据将无法正确地填充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的程序必须对应一个分支。
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形式的数据表示都是受惠于硬件的提升。因此,现在,一般而言,很微小的存储空间占用和性能的影响并不需要设计人员特别的关注,他们要更多关注的往往是如何使逻辑简化,如何使系统更具扩展性,可维护性和移植性上。
(出处:http://www.cncms.com)
更多精彩
赞助商链接