我已經(jīng)不止一次聽(tīng)人說(shuō)O-R Mapping的技術(shù)已經(jīng)很成熟了，事情真的是這樣的嗎？

以前我跟人說(shuō)，我要優(yōu)化現(xiàn)有的O-R Mapping引擎，提高速度，朋友告訴我，O-R Mapping是一種很成熟的技術(shù)了，沒(méi)什么好研究的。我沒(méi)有反駁，當(dāng)我找到更好的方法把現(xiàn)有的O-R Mapping優(yōu)化，提高數(shù)倍的性能后，另外一個(gè)朋友知道這件事后，跟我說(shuō)，O-R Mapping是一個(gè)很成熟的技術(shù)，你能夠提高數(shù)倍的速度，原來(lái)的設(shè)計(jì)一定很爛。

在我看來(lái)，他們的想法都不正確。O-R Mapping一直以來(lái)存在一個(gè)難題，就是速度，這個(gè)問(wèn)題沒(méi)有解決之前，就不能說(shuō)O-R Mapping的技術(shù)已經(jīng)成熟了。O-R Mapping還存在另一個(gè)問(wèn)題，就是使用的方便性。Entity Bean在性能和易用性方面都做得很差，Hibernate也做得不好，聽(tīng)說(shuō)TopLink性能不錯(cuò)，但應(yīng)該也不會(huì)太好。我看過(guò)TopLink的一些例子，覺(jué)得其接口不直觀。

現(xiàn)在O-R Mapping的產(chǎn)品處于戰(zhàn)國(guó)時(shí)代，群雄無(wú)首。用徐少春的話來(lái)說(shuō)，所有的都是小猴子，還沒(méi)有出現(xiàn)一個(gè)大金剛，。。。

我希望能夠在這個(gè)方面有所突破，最終造就一個(gè)大金剛！！

 

文章來(lái)源:http://www.cnblogs.com/jobs/archive/2004/12/24/81643.html

Hibernate 3作了一些改進(jìn)，改進(jìn)了一些原來(lái)很顯而易見(jiàn)的缺點(diǎn)。例如加了抽象語(yǔ)法樹(shù)，但是在Hibernate 3.0 Beta1中，感覺(jué)還是有些不大成熟。從代碼可以看出，Hibernate 3.0 Beta1的HQL AST使用了antlr，我向來(lái)不大喜歡這種使用yacc、antlr等生成的文法分析和AST。

ast部分的代碼是josh提供的，看來(lái)gavin并不熟悉文法分析等編譯技術(shù)，ast是否能夠很好發(fā)揮作用，現(xiàn)在還難說(shuō)...

在ObjectSpaces中，提出了兩種查詢分類：Object Query和Data Query。這種提法很好的，Object Space的一些思路是很好的，可惜這個(gè)項(xiàng)目不知道為什么取消了。

我認(rèn)為HQL，抽象得不好，他引入了一種無(wú)需寫連接條件的連接NATURAL JOIN，其實(shí)連接條件在元數(shù)據(jù)中描述了。我認(rèn)為這種做法是很不好的！

文章來(lái)源:http://www.cnblogs.com/jobs/archive/2004/12/23/80812.html

最近安裝了My Sql 5.0.1，完全是圖新鮮而安裝的。發(fā)現(xiàn)原來(lái)的程序跑不了了，追查的結(jié)果是,MySql在5.0中修改了Show Table Status的返回結(jié)果。

原來(lái)Show Table Status返回的數(shù)據(jù)中包含一個(gè)列TableType，在5.0中沒(méi)有了這一個(gè)列，郁悶啊。

文章來(lái)源:http://www.cnblogs.com/jobs/archive/2004/11/10/62422.html

今天安裝了PostgreSQL 8.0.0 Beta 4，感覺(jué)似乎不錯(cuò)。PostgreSql 7.x需要安裝模擬器才能夠在Windows上運(yùn)行的，在8.0中，直接支持Windows了。

下載地址：

http://www.postgresql.org/news/235.html

他的JDBC驅(qū)動(dòng)程序從這里可以獲得：

http://jdbc.postgresql.org/

postgresql的JDBC驅(qū)動(dòng)程序似乎寫得挺不錯(cuò)的，有專門針對(duì)大對(duì)象的接口。

 

PostgreSQL本身就附帶圖形管理工具，不是很好用，但也不算太差。如下面的截圖：

文章來(lái)源:http://www.cnblogs.com/jobs/archive/2004/11/01/59428.html

大數(shù)據(jù)量遷移的一些心得

最近遷移了一個(gè)大約30G的SQL SERVER 2000的數(shù)據(jù)庫(kù)到DB2 8.1。以下為遷移的工作心得：
1、在大表的遷移中，不要因?yàn)閳D快而先遷移數(shù)據(jù)然后建立主鍵索引。因?yàn)楹苡锌赡芟到y(tǒng)沒(méi)有足夠的資源完成這樣的操作。我在遷移超過(guò)400萬(wàn)行記錄的表時(shí)，等遷移完數(shù)據(jù)后，再建立Primary Key時(shí)，提示資源不足而出錯(cuò)。

2、插入數(shù)據(jù)可以使用DB2的一個(gè)特色功能，一個(gè)Insert語(yǔ)句，可以帶多個(gè)Values。
INSERT INTO T (F1, F2) VALUES (?, ?), (?, ?) , (?, ?), (?, ?), (?, ?)
這樣的方式，要比addBatch的方式要快。

3、主表和從表的外鍵關(guān)聯(lián)問(wèn)題
例如主表為A，從表為B。
TABLE A (
A1 VARCHAR(50)
)
TABLE B (
B1 VARCHAR(40),
CONSTRAINT Fk_B FOREIGN KEY (B1) REFERENCES A (A1)
)
外鍵 Fk_B (B1) REFERENCES A (A1)
其中A表數(shù)據(jù):
A1
'aa'
'bb'

B表
'Aa'
'bB'

這在SQL Server中，缺省的建庫(kù)不區(qū)分大小寫，它是合法的。遷移到DB2中時(shí)，由于庫(kù)是大小寫區(qū)分，出現(xiàn)錯(cuò)誤。

建議：在SQL Server中，我們直接使用區(qū)分大小的選項(xiàng)建立數(shù)據(jù)庫(kù)，與所有的支持的數(shù)據(jù)庫(kù)一致。這樣我們的程序更容易發(fā)現(xiàn)多數(shù)庫(kù)支持的錯(cuò)誤。

4、海量數(shù)據(jù)庫(kù)的遷移工作耗時(shí)很長(zhǎng)，建議以后規(guī)劃這類工作時(shí)，給予更多的時(shí)間，否則很容易出現(xiàn)延遲或者無(wú)法完成任務(wù)的情況。

文章來(lái)源:http://www.cnblogs.com/jobs/archive/2004/10/03/48683.html