從外部系統連接表與ID時的最佳做法是什麼？

我們的團隊經常遇到需要將我們的表加入來自數據庫之外的標識符的情況，例如使用公共數據存儲庫中的匹配關聯下載數據。從外部系統連接表與ID時的最佳做法是什麼？

我知道基本的兩種方法。我們最常用的一個涉及批處理IN子句。當我們加入大於1000個項目時，我們有一個實用工具，用於在單獨的查詢中透明地包裝長的IN語句。

隨着4查詢的5個項目和批次的限制：

SELECT foo.id, foo.data FROM foo WHERE foo.id IN ($MANY)

變爲：

SELECT foo.id, foo.data FROM foo WHERE foo.id IN (?,?,?,?) 
SELECT foo.id, foo.data FROM foo WHERE foo.id IN (?)

這種方法可行，但似乎相當缺憾。

有時候可以使用的替代方法包括創建臨時表，插入值和加入普通表。這個解決方案對於最終查詢來說似乎更加標準，因爲您只是簡單地加入，就像數據在數據庫中一樣。但是，創建臨時表似乎並不能以符合ANSI SQL的方式完成。

表現似乎與IN方法大致相同，並且如預期的那樣獲得少量外部價值。

以ANSI標準方式解決此問題的最佳做法是什麼？

編輯：關於性能指標，我們對應用程序代碼進行了基準測試。這包括插入臨時表的開銷。同樣，對於IN子句，它包括批量處理的開銷。

來源

2013-11-01 Daniel Nesbitt

你應該避免view..Use的表現來看內部查詢加入如果u從外部表或數據需要的是來自同一個表，然後使用自連接，但要避免內部查詢，以獲得性能 – Kuldeep

創建臨時表，然後填充似乎是額外的處理。當你說他們差不多時，你是否計算了添加所有記錄所需的時間？如果是這樣，請嘗試使用數千條記錄幾次，看看每種方法是否仍然需要相同的時間。 –

您正在使用哪些DBMS？ Postgres的？甲骨文？ –

在這種特殊情況下，由於您只能通過ID進行匹配，所以使用IN子句的解決方案是最好的方法，它比聯接更有效。一個連接，即使在這種簡單的情況下，你的臨時表只有ID，總是會在IN子句中產生大量的開銷。如果兩個選項似乎都以相同的速度在系統上運行，因爲您的表有幾千個ID的小表，但是如果增加臨時表中的記錄數，則IN子句總是會贏。

我的2美分

來源

2013-11-01 18:12:52

從外部系統連接表與ID時的最佳做法是什麼？

回答

相關問題