2014-07-05 107 views
2

假設有兩種實體類型:Book(主鍵爲bookId)和Author(主鍵爲authorId)。一位作者寫了0 ... n本書。因此使用@ManyToOneBook中引用AuthorJPA性能:實體或實體ID作爲查詢參數?

如果我們要檢索某個作者寫的所有的書,我們可以做兩件事情在JPQL(如NamedQuery):

  1. SELECT b FROM Book b WHERE b.author = :author(實體參數)
  2. SELECT b FROM Book b WHERE b.author.authorId = :authorId(主鍵ID實體作爲參數)

在第一個選項中,我們必須注意傳入的對象確實是Author類型,並且它已經有一個主鍵。

但是:在上述兩個選項中,性能是否存在差異?我認爲(2)比較便宜,但(1)可能更容易針對JPA提供者進行優化。在這個問題上是否有性能測試或文獻?

我們可以假設Author實例(我們想要搜索的書)已經被加載(例如,在響應中查看他/她的個人資料),所以沒有額外的代碼編寫工作來傳遞整個對象或只是它的書籍搜索方法的ID。但是執行速度有差異嗎?也許取決於使用的JPA提供程序?

+5

我認爲對於第一種情況,生成的查詢將與第二種情況相同。所以沒有觀察到性能差異。 –

+1

同意,在本地查詢中沒有實體參數,因此將生成相同的本機查詢。 jpa中的實體比較轉換爲本地查詢中的主鍵比較。沒有不同。 –

+0

使用哪種方法更好? –

回答

3

我測試了這兩個查詢,結果sql是一樣的。

回答你的問題的第二部分 - 有很多相關文獻,但我可以特別推薦Pro JPA 2, 2nd Edition by Mike Keith , Merrick Schincariol

如果您想手動測試查詢,則可以觀察由JPA查詢產生的SQL查詢。一種方法是瞭解您的JPA提供商,並瞭解他爲此目的提供的選項(例如,Hibernate提供選項hibernate.show_sql)。第二個選項(在我看來 - 更好)是使用諸如log4jdbc之類的工具,它是JDBC驅動程序和持久性提供程序之間的一個附加層(簡化),並且可以記錄發送到數據庫的所有查詢及其參數。它也可以測量每個查詢的時間花費,所以我認爲它是性能測試的理想工具。