2011-04-27 57 views
2

我想知道是否有可能使用SQL.2003對象類型(aka STRUCTs,又名非標量類型)來執行ORM。我們可以使用ORM的用戶定義(非標量)SQL類型嗎?

背後的想法是通過直接從數據庫中檢索完整對象來避免"n+1 selects" problem。渴望「FetchMode.JOIN」的排序,但在數據庫中的

是否有任何支持SQL對象類型的ORM框架fpor Java或.Net?

至少JDBC有getObject method而且我也發現了user-defined types in ADO.Net

作爲Oracle開發人員爲例,我可以向數據庫爲中心的方法有偏差,我也沒有以前使用ORM。但Oracle的功能Object Views可讓您編寫來自多個關係表的對象。我敢打賭,這些數據可能比將所有單條記錄從數據庫中提取出來要快得多,更不用說發出n + 1個選擇。

+0

是的,數據庫中的對象視圖比將數據拉出數據庫快幾個數量級。你是否看過Oracle數據庫中的Java,以及它是否可以將本地對象視圖讀爲Java非標量類型? – 2012-02-08 23:34:58

回答

1

我是jOOQ的開發者,我努力使jOOQ正是你所需要的。 jOOQ目前支持所有這些Oracle特性:

  • 所有類型的SQL構造,包括嵌套的選擇,走樣,聯合運營等
  • 存儲過程和函數
  • VARRAY類型(映射到Java數組)
  • UDT類型(映射到Java對象)
  • 它們的組合

更多的支持,將在不久的將來會增加,對高級Oracle概念,如

  • 表類型
  • CURSOR,REF遊標類型
  • 其他集合類型

對象的意見,目前不像您所描述的那樣支持,但我會清楚地將它們放在路線圖上。

查看更多關於http://www.jooq.org

+0

盧卡斯,謝謝你的回覆。我終於研究了jOOQ,LINQ和其他ORM工具,試圖弄清楚它們是如何相互關聯的,以及可能的優點和缺點。畢竟,我會試圖說服客戶去使用ADO和/或DAO,並儘可能保持midlle層。如果他們仍然想要走ORM,那麼我們必須避免UDT,因爲它們在平臺和數據庫中不是同等支持的。也許jOOQ仍然是一個選擇,但我當然不具備使他們不使用Hibernate的專業知識。 – 2011-05-02 14:41:55

+0

@ hal9000:感謝您的反饋。 Hibernate也是一個優秀的數據庫抽象庫。它只是取決於用例... – 2011-05-02 15:11:30

+0

只是看着jOOQ。它絕對解決了n + 1問題。 Java對象中的SQL業務邏輯。偉大的項目顯示出巨大的希 – 2012-02-08 23:39:34

相關問題