左側是否加入代碼味道太多？

Question

如果您有例如> 5左聯接的查詢是一個代碼味道，有...

• 什麼問題你的設計？
• 你在一個查詢中做得太多了嗎？
• 你的數據庫過於規範化了嗎？

Answer 1

這對某些設計來說是完全合法的解決方案。

說當你有一個層次一個對許多喜歡Customer關係 - Order - Basket - Item - Price等，它可以在任何級別上未配備：一Customer可能沒有Orders，一個Order可以沒有Baskets等

在這種情況下，你發出這樣的：

SELECT * 
FROM Customer c 
LEFT OUTER JOIN 
     Order o 
ON  o.CustomerID = c.ID 
LEFT OUTER JOIN 
     Basket b 
ON  b.OrderID = c.ID 
… 

注意，這可能是在某些情況下效率低下，並且可以與被替換或NOT EXISTS（如果您只想知道相應的記錄存在或不存在於其他表格中）。

看到這篇文章在我的博客的性能細節：

• Finding incomplete orders - 如何從NOT EXISTS

Answer 2

更換LEFT JOIN的在這個意義上受益，它的東西，你可以/應該調查我說是的。通過考慮一些觀點，你可能會得到更好的效用和維護。

從某種意義上說，它是「糟糕的代碼」否，這可能很容易合理，特別是對於較大的數據庫，現代數據庫可能會優化任何低效率。

Answer 3

儘管如果你發現自己一次又一次地寫同樣的查詢/程序，使用相同的連接到相同的表， 它可能是一個創建視圖的候選人，只是爲了簡化你在將來查詢，並減少你需要改變的觸摸點的數量，如果你的架構變化

Answer 4

很多時候你可以通過創建幫助者視圖來減輕視覺氣味，我不認爲有一個硬性規定多少左連接被認爲是不好的。

與過程編碼不同，將SQL細分爲小塊和小塊可能導致查詢效率低下。

Answer 5

某人回答這個問題幾乎是不可能的，並試圖創建這樣一個任意的規則將毫無意義。

左連接是一種完全可以接受的連接類型，映射到一個非常普遍的需求：讓我所有的x，如果他們有關聯，然後獲得這些。

Answer 6

您的結果我因人而異

任何不尋常的可能是一個代碼氣味的東西。像Quassnoi說，這可能是完全合法的。真正深入的報告並不少見，需要瘋狂的連接才能正確拼湊信息。這並不意味着開發人員應該查看數據庫的非規範化。

Answer 7

不，完全沒有。構建一個在某些查詢中使用大量左連接的數據庫設計是完全合法的。

說了這麼多我一般喜歡構建數據庫，以便在需要外部連接的案件數量是有限的經驗往往表明，使用起來都比較容易出錯，有可能引起該（複雜）查詢維護問題。作爲一個有趣的歷史遺留，IBM DB2的早期版本僅在大型機上運行時，不支持外部連接（Oracle和Ingress在當時都是一個主要賣點）。這導致了數據庫設計中一些有趣的問題，因爲有必要確保數據庫的所有預期數據訪問需求都可以使用內部連接來解決。

Answer 8

我認爲必須使用許多聯接（例如處理規範化的數據）不是代碼異味，而是一種跡象表明，您可能無法在正確的位置工作。根據我的經驗，那些擔心查詢中的連接數量的人在數據庫中開發得太多，而在公開數據的應用程序和報表中卻不足夠。數據結構必須足夠靈活以支持大量的用途，這就是爲什麼標準化在某種程度上很重要。

在構建當今的企業應用程序時，開發人員可以利用昨天的成就在高於SQL等甚至XML技術的抽象層次上工作，以便在減少工作量的同時提供更多價值。有一些工具，即報表編寫器，代碼生成器，ORM，實體框架等，它們將人工構建SQL的低級工作抽象出來，並將爲您執行連接。大多數人都知道正在使用的SQL方言（例如，Oracle 9和MySQL 3），並且可以生成對該方言最有效的SQL語法;這意味着他們可以創建比您更好的連接。

但是，這些工具在沒有足夠標準化的關係環境中工作得很差或根本不工作。對我而言，這是一種「發展」氣味表現出來的地方;如果一個已建立的數據訪問工具無法理解我構建數據的關係，那麼我可能需要尋找更加規範化的方式來創建這些關係，並從中獲得遠遠超過使用該工具的好處。通常，第二和第三個normal form之間的某處是甜點;儘管總是存在小範圍的關係數據，其中更高程度的標準化是有意義的並且增加了價值。

乾杯， 特拉維斯