實際上有多少個連接可行

這個問題可能更適合程序員.stackexchange。如果是這樣，請遷移。實際上有多少個連接可行

我目前正在思考典型數據模型的複雜性。大家都知道數據模型應該是標準化的，但另一方面，規範化的數據模型需要相當多的連接才能在以後重新組合數據。根據所涉及的表的大小，連接可能是昂貴的操作。所以我試圖弄清楚的問題是，人們通常會如何進行這種權衡？即在實踐中，在設計數據模型時，您會在典型查詢中找到多少接點？在單個查詢中計算多個連接時，這會特別有趣。

舉個例子，假設我們有擁有房屋的用戶，其中有房間，其中有抽屜，其中包含物品。在上面解釋的用戶，房屋，房間，抽屜和物品的表格中進行標準化時，以後需要我加入5個表格，當獲得屬於某個用戶的所有物品時。這對我來說似乎非常複雜。

最有可能也會涉及表格的大小。用少量數據連接五個表格並不像三個具有數百萬行數據的表格那麼糟糕。或者這種考慮是錯誤的？

來源

2012-06-29 LiKao

5表只有4個連接。並不是很多。在所有查詢中，您不需要全部5個表中的數據。如果你有更少的表（非規範化），你將有更大的表來處理所有查詢。 –

就像ypercube說的，5桌並不多。（我通常試圖限制單個查詢中的表連接，以便在屏幕上可視化 - 這意味着大約20個表格左右:)）但是如果在示例應用程序中大多數負載來自用戶項目查詢，那麼您可以考慮添加一些冗餘，將用戶標識添加到項目表中 - 確保使您的特定查詢更快。當然，你必須仔細設計你的記錄插入和更新邏輯，以避免產生衝突的數據。像往常一樣，沒有「一刀切」的解決方案。 – Arvo

有reasons for the Database Normalizations，我看到有超過20個表和子查詢連接在一起的查詢，很長一段時間工作得很好。我發現規範化的概念是一個巨大的勝利，因爲它允許我在現有的工作應用程序中添加新功能，而不會影響到目前的工作部分。

數據庫具有不同的功能，使您的生活更輕鬆：

你可以創建視圖的最常用的查詢（雖然這不是唯一的用例視圖）;
某些RDBMS提供了Common Table Expressions（CTE），它允許您使用命名的子查詢和遞歸查詢;
某些RDBMS提供了擴展語言（如PL/SQL或PL/pgSQL），允許您開發自己的函數來隱藏模式的複雜性，並僅使用API調用來操作數據。

一段時間後，有一個相關的問題How does a SQL statement containing mutiple joins work?它也可能是值得一看的。

使用規範化的數據庫開發應用程序更容易，因爲通過適當的方法，您可以通過視圖/函數來隔離模式，並使應用程序代碼免於模式更改。如果您將採用非規範化設計，那麼設計更改可能會影響您的大量代碼，因爲非規範化系統往往會以犧牲可能性爲代價進行高度性能優化。

來源

2012-06-29 07:52:21 vyegorov

完全標準化的數據模型在性能上成本較高，但更易於改變。對於一個查詢而言，數據模型是一個很好的調整，但性能會變得更好，但是當規格發生變化時您必須付出代價。

所以也許問題是你的數據模型（查詢）的使用會改變很多？如果不;不要規範化它們只針對特定查詢調整它們（問問你的DBA）。否則，規範化，只是通過查詢執行計劃，如果您使用多個連接，我不能給你一個具體的數字。

來源

2012-06-29 07:11:42 Hubert

規範化數據庫本身就是一種藝術形式。
如果您正確構建連接，則只會抓取所需的列。
運行帶有多個表的數百萬條記錄的查詢並加入所需字段的速度應該會更快，然後如果您有一個或兩個包含所有記錄的表，則會這樣。在第二個例子中，您正在檢索所有數據並對其進行排序，這將是一個編碼噩夢。
只有檢索請求的數據，MySQL纔是非常好的選擇。
僅僅因爲查詢很長並不意味着速度較慢。
我已經看到了超過20行代碼非常快的查詢語句。

對你寫的查詢有信心，如果你不寫測試腳本，請親自嘗試。

來源

2012-06-29 07:13:13

哦，是的，並回答你的其他問題。你會覺得可以接受多少加入？答案將盡可能多。:) –

爲了解決你的問題的答案是：

http://en.wikipedia.org/wiki/Database_normalization

如果性能變得非規範化使用這些問題是可以解決的一個問題。預先考慮這個步驟（除非你已經有一個可預期的負載）不應該完成。在非常需要和基於測量的情況下進行非規範化。

來源

2012-06-29 07:36:16

實際上有多少個連接可行

回答

相關問題