5種Java數據計算層的解決方法
JAVA的數據計算層主要是為了降低應用程序層和數據持久層之間的耦合性，分擔它們的計算壓力。它應當符合如下特征：
5種java數據計算層的解決方法
1. 可以統一的計算來自任意數據持久層的數據，不僅包括數據庫，也包括非數據庫的Excel/Txt/XML。其中對最常見的結構化數據的計算是重點。
2. 可以統一的進行不同種類數據源之間的相互計算。不僅包括異種數據庫之間，也包括數據庫和非數據庫之間的計算。
3. 數據庫和計算層、計算層和JAVA代碼之間要有盡量低的耦合性，可以方便移植。
4. 可以是非JAVA架構，但必須能和JAVA方便的集成。
5. 要有較高的開發效率，包括腳本編寫，可讀性，調試，日常維護。
6. 復雜計算目標和大數據計算是流行趨勢，數據計算層應該能直接支持。
考察了5種數據計算層:Hibernate，集算器，SQL，iBatis，R languae?？疾斓闹笜税ǎ撼墒於?、低耦合性、腳本編寫、集成、界面友好性、性能、復雜計算、大數據支持、非數據庫計算、跨庫計算、調試方便性。
Hibernate
Hibernate是輕量級的ORM框架，由Gavin King創造，現在屬于JBOSS。它是非分布式環境中(intranet)中優秀的數據計算層。它具有徹底的基于對象的訪問方式，而集算器和iBatis只能算半對象或類對象。
Hibernate幾乎做到了計算腳本、JAVA代碼、數據庫之間的徹底解耦。但計算能力不足使它仍然在很多地方依靠SP/SQL，這是個尷尬的問題。
另外EJB的JPA屬于數據計算層協議，但考慮到Hibernate是實際上的JPA，所以不介紹它了。
成熟度：4星。經過10多年的市場檢驗，Hibernate已經非常成熟。
低耦合性：4星，這是Hibernate出現的原因。但本地SQL仍然是不可避免的，難以完美移植。
腳本編寫：2星。Hibernate的計算方式是對象引用和HQL，前者最容易，給5星;但后者的學習難度比SQL高，而且調試極困難，開發效率不如SQL，2星;另外有些計算還是不得不依靠SQL，2種語言混用，困難，給2星。平均3星。
集成：2星。Hibernate是純java架構，只需要復制jar包和N個映射文件，并利用好session，入門比較容易。但駕馭Hibernate的緩存是必修課，這需要極高的架構設計能力，不建議普通程序員接觸。當然，ORM的這種天生的缺陷在其他數據計算層并不存在。
界面友好性：0星。Hibernate有對象生成器;但缺乏最重要的HQL圖形化設計界面，等于沒有GUI。
性能：3星。支持3級緩存，雖然一定不如SQL，但據我個人經驗其綜合性能達到了SQL的60%。
復雜計算：0星。不支持復雜計算。需要依靠SQL/外部工具實現。
大數據支持：1星。不直接支持hadoop架構，但有人在研究。
非數據庫計算：0星。不直接支持非數據庫的計算。
跨庫計算：0星。不直接支持庫間的計算。每個HQL只支持單庫。
調式方便性：0星。很難調試，對程序員來講，這是致命的。
集算器
集算器是最近出現的新型JAVA計算層，擅長復雜的、跨庫的計算。和其他數據計算層不同，集算器只是將SQL作為一種數據源，而取到數據后的計算則完全和SQL無關。PJA/hibernate則被迫開放SQL接口，用來實現自己處理不了的計算。
成熟度：1星。在市場出現僅1年，應用的廣度和深度都不如其他數據計算層。
低耦合性：4星。腳本獨立于數據庫和Java代碼，算法和具體數據庫無關，耦合性低?？梢暂p松移植到不同的數據庫。因為輸出接口為JDBC，所以也可以輕松移植到報表，這是其他數據計算層所不具備的特征。
腳本編寫：4星。腳本寫在網格中，單元格可以按格名調用，可以直接觀察每一步的計算結果，復雜目標可以分解為簡單步驟。但它的語法偏向對象引用(但不是對象)，與偏向描述語句的SQL風格不同，需要學習。不過JAVA程序員到底喜歡哪一種，還很難說。
集成：5星。集算器是純JAVA架構，輸出JDBC接口，集成不需要學習。用過任何一種數據庫的程序員都可以無障礙使用。
界面友好性：4星。獨立的圖形化編輯器，使用方便直觀。但幫助系統不夠友好。
性能：2星。全內存計算，數據量不能太大。
復雜計算：5星。這是集算器出現的原因。
非數據庫計算：3星。支持Excel/Txt，但不支持xml或webService.
大數據支持：4星。能訪問HDFS，同步宣稱支持并行計算，但細節還不太了解。
跨庫計算:5星。集算器語法與具體數據庫無關，天生支持跨庫計算。
調式方便性：5星。調式功能完善，而且使用非常方便，可以觀察到最細粒度的計算步驟。其他數據計算層遠遠達不到這種方便性。
SQL
SQL/SP/JDBC在這里屬于一類，這是老牌的數據計算層，性能和靈活性是它的優勢。但隨著新情況的不斷出現，單純用SQL已經難以滿足需求，比如： JAVA開發規模的擴大，數據量的劇增，復雜計算問題的涌現。雖然SQL得高分的指標不多，但都是權重最高的。
成熟度：5星。最成熟的。
低耦合性：0星。耦合性極高。除了在實驗室之外，幾乎不可能寫出與數據庫無關，與代碼無關的計算腳本。
腳本編寫：3星。SQL實際很難寫出也很難維護，需要大量的時間去學習，好在SQL非常成熟，資料豐富論壇很多。但各種數據之間的不兼容也是個巨大的障礙，這是Hibernate之所以流行的主因。
集成：5星。JAVA程序員的第一課就是用JDBC連接數據庫。
界面友好性：5星。有大量的SQL開發工具，成熟度都很高，我自己用過不下10種。
性能：5星。數據庫直接支持的語言，性能最高。
復雜計算：3星。SQL適合普通的計算問題，可以解決復雜問題但非常困難(而Hibernate是完全不能)。SP的出現并不能有太大的改善。代碼難以拆分，復雜目標難以分解為簡單步驟是主因。
大數據支持：1星。個別數據庫廠商表示已經支持大數據了，但這讓SQL語句的不兼容程度加劇了，而且我也沒見過成功案例。
非數據庫計算：1星。不直接支持。采用ETL/數據倉庫可以達到這個目的，但代價巨大。
跨庫計算：1星。個別數據庫支持，但性能較差，也可以采用DBLink和link server等中間件勉強支持，但離“自由方便”的程度還差得遠。
調式方便性：1星。很難調試，難以觀察中間結果，只能全部執行完才能看到最終計算結果。唯一的辦法是“以調試為目標進行編程”，即刻意建造大量臨時表。
iBatis:
簡單敏捷因此強大的數據計算層。和Hibernate不同，它鼓勵寫SQL，所以學習成本最低。同時它用最小的代價實現了計算腳本和JAVA代碼的解耦，只用20%的代價就實現了hibernate 80%的功能。另外沒實現的20%是計算腳本和數據庫的解耦。
復雜計算環境是它的弱項，比如：分布式計算、復雜計算、非數據庫計算、跨庫計算。
成熟度:4星。iBatis經過了十幾年市場的考驗，是我最喜歡的框架之一。但對緩存的支持不足仍然是缺陷。
低耦合性：2星。SQL可以無縫替換，但仍然是針對具體數據庫的SQL。事實上后者是數據庫的問題，廠商要粘住客戶，所以SQL不兼容，讓你難以遷移;但程序員不愿讓粘住，非要遷移。
腳本編寫：3星。它就是SQL。
集成：4星?；緵]有難度，初學者半天時間都可以熟練掌握。
界面友好性：4星。沒有圖形化計算過程設計界面，但可以借用SQL工具。
性能：3星。性能比SQL略低，主要是resultSet和map/list之間轉化需要多花費一點時間。另外緩存支持不如hibernate好。綜合比起來兩者區別不大。其實我認為引入ORM的同時引入性能問題就是失敗的。
復雜計算：3星。同SQL，比hibernate強。
大數據支持：1星。同SQL
非數據庫計算：1星。同SQL
跨庫計算：1星。同SQL
調式方便性：1星。同SQL
R語言
R語言不易和JAVA集成，但強大的計算能力和廣泛的社區支持，以及大數據的特性使我不得不提到它。另外跨庫的計算、非數據庫的計算、模型計算也是它的強項。當然，在各種數據計算層中，它也是最難學習的。
成熟度：5星。R語言的歷史僅次于SQL。無數的社區在熱烈討論R。尤其是大數據時代。
低耦合性：4星。R語言和集算器在這方面沒區別。
腳本編寫：3星。這方面R和集算器很像，區別是集算器更敏捷代碼更靈活，對結構化數據的支持更專業，而R內置了大量模型算法。所以基本持平。
集成：1星。R不是JAVA架構，很難集成進JAVA，本來性能就不高，集成后性能更是大幅度降低。
界面友好性：3星。有專門的IDE界面，但很粗糙，實際價值不大，這也是開源產品的通病。
性能：2星。全內存運算，難以應付大數據量。
復雜計算：5星。同集算器類似。
大數據支持：3星。有R與Hadoop的結合機制，但JAVA體系與非JAVA體系之間的結合并不容易，性能損失較大。
非數據庫計算：5星。同集算器類似。
跨庫計算：5星。同集算器類似。
調式方便性：2星。勉強算有調試功能，但很不專業。
