用於存儲的地方

我必須存儲有關學校和大學的數據屬性數據庫結構（如語言課程，更多的實體還計劃）。用於存儲的地方

數據的名單上有存儲：

可用的學習計劃
住宿可能性
情況特殊食品的飲食
等

所以我創建的表爲學校和單位：

Place (place_id, name, city_id ...) 
School (place_id (FK), school_type ...) 
University (place_id (FK), ...)

和表格選項：

Accomodation (accomodation_id, name, description ...) 
Activity (activity_id, name, category ...) 
...

而且因爲它總是可能的，它會多一種選擇我束縛在一起的桌子像這樣的：

Accomodation_to_place (place_id, accomodation_id) 
...

但我發現即使更新甚至從整個事情中獲取數據也很困難。我必須做14個連接和7個GROUP_CONCAT（）才能獲得我需要的所有信息。

所以我想一定有我的數據庫設計中的一些嚴重缺陷。我想問一些如何讓它變得更好/更容易的想法。

來源

2012-11-29 Alexander

如果可以顯示設計的結構會更好，如果你還不太適應14連結和..你可以創建一個視圖表，代碼將簡化一點 – jcho360

通過迄今爲止提供的設置，我沒有看到你的想法存在明顯的缺陷。看起來你似乎有很多不同的東西，而且他們之間有很多關係。然而，如果你希望能夠提取大量有關某個特定地點的數據，這實際上意味着你希望在特定的地方獲得文檔。你看過[MongoDB]（http://www.mongodb.org/）嗎？它的設計從頭開始以文件爲中心進行存儲。 – tmesser

@YYY MongoDB看起來和我需要的完全一樣，但現在已經太晚了（我正在開發的項目距離截止日期還不算太遠）。但是，謝謝你的想法。看起來現在我會堅持我的14個連接。 – Alexander

數據庫標準化的目的主要是避免在某種程度上是多餘的，易受數據異常存儲數據。

這有時會導致複雜的查詢檢索所有數據，但那是因爲你正在製作信息的性質是複雜的。儘管如此，規範化的設計對於避免數據變得混亂的目的來說更好。

我建議，如果你有有很多的DISTINCT和GROUP_CONCAT這樣複雜的查詢，你可能試圖獲取在單個查詢太多的信息。使用兩個或三個查詢並不一定是有害的，並且通過讓代碼更易於讀取，維護和調試，您可能會受益匪淺。

我寫了一篇關於這個問題在我的書題爲「意大利麪條查詢」一章中，SQL Antipatterns: Avoiding the Pitfalls of Database Programming

來源

2012-11-29 19:27:46

用於存儲的地方

回答

相關問題