瞭解大型mysql數據關係

我想教自己如何使用SQL，即mysql。瞭解大型mysql數據關係

我想了解的是如何處理同一個表中的許多不同類型的數據。假設我正在構建一個Web應用程序，並且我有許多不同的內容類型（博客項目，評論項目，文件，頁面，表單），我需要爲它們存儲不同的數據字段。我是否會爲每種不同的內容類型創建一個新表格，因爲每種內容類型都有其獨特的字段要求，還是有更好的方法來執行此操作？爲每種類型的內容創建一個新表似乎有點過分。如果我在我的網絡應用程序中有30種類型的內容，那麼對於這些類型而言，這將是30個表格，這似乎有點多。而且，如果我有一個新的內容類型，我將不得不創建一個新表，其中包含我需要的所有必需字段。

當我有許多不同類型的內容時，是否有更好的方式來做這樣的事情？每種內容都需要不同的數據字段，需要進入數據庫？我可以以某種方式檢查以查看內容是什麼類型，然後選擇另一個包含所有不同字段類型的表？

對做什麼有點困惑。

來源

2010-02-08 Nic Hubbard

只是舉一個例子：

堆棧溢出本身使用的問題和答案在同一個數據庫表（稱爲主題）。即使這兩種類型的數據不相同，網站創建者也認爲它們足夠類似，可以將它們放在一張表中。有一個PostTypeId字段說明這個帖子是一個問題還是一個答案。在答案上，標題字段將爲空，在問題上，其他列可能會被忽略。

另一方面，評論處於不同的表格中。當然你理論上可以把它們放到相同的Posts表中並且有一個PostTypeId用於註釋。但是這會產生的開銷（由於評論的輕量級）證明創建一個新表格是合理的。

我知道這不是一個真正的答案，其他開發人員甚至可能決定將問題和答案放在不同的表格中;但它提供了一些觀點。長話短說：這取決於:)

來源

2010-02-08 08:34:00 balpha

是的，這符合我所尋找的內容。只有在許多內容類型較大的情況下。 – 2010-02-08 08:36:56

素描互動

先試着不要去想數據庫設計，但企業應如何自己之間的互動。把它看作是每個實體都有自己的類，它代表了所需的數據。

用鉛筆和紙張勾畫這些實體之間的相互作用，以及您試圖完成什麼樣的相互作用（或關係）總是一個好開始。 Learning the Database design process

可擴性和重用

例如，你想有一個User，它可以發佈BlogPost s各自的博文可以有一組Tag S和相關集Comment秒。 Attachment s可以注入到BlogPost中，也可以註釋到註釋中。

可重用性和可擴展性是關鍵。在勾畫您的交互時，嘗試隔離依賴關係。以OO方式思考它。我們再來探索一下Attachment。您可以創建一個附件表，然後通過創建BlogPostAttachment和CommentAttachment來擴展附件，您可以在其中輕鬆創建這些可靠實體之間的關係。這會創建一個可輕鬆擴展的內容類型，您可以在例如。 UserDetailsAttachment

ORM的搶救

通過研究Object relational mappers示例代碼使用像Doctrine或Propel可以把握表extendabity一些想法。實際的例子總是最好的。

相關SO問題，這些問題可能會在

我知道有興趣，這是一個很長的路要走，但考慮創建具有許多關係的大型DB應用程序的因素d實體類型最好使用ORM的長期幫助

來源

2010-02-08 08:41:29

我想我在這裏找的是一個EAV模型。這是一個好主意嗎？ – 2010-02-08 17:04:37

不完全..我爲您提供了一種簡單的方法，通過構建靈活的數據庫模型來很好地擴展您的代碼。 ORM使您的編碼更容易，更少痛苦。 EAV模型會因數據庫完整性受損，您必須自己完成所有檢查。 – 2010-02-08 19:00:10

您不必害怕使用許多表格 - 數據庫會很樂意處理大量的表格而不抱怨。如果讓每個內容類型都有它自己的表，你會得到一定的優勢：

簡單：每個表可以相當簡單，約束簡單。例如，如果ContentType1具有與另一個表的關係的字段，則可以在數據庫設計中使用該外鍵，並且RDBMS將爲您處理數據完整性。
索引編制效率：如果ContentType2需要按日期進行索引，但ContentType3需要按名稱進行索引（舉一個簡單的例子），將它們放在兩個單獨的表中意味着每個索引都存在它所需的數據沒有其他的。將它們組合在一個表中意味着您需要兩個索引來涵蓋組合的數據集，這是更加混亂的，並佔用更多的磁盤空間。

如果需要輸出組合兩種內容類型，這兩個表的聯合列表既方便;如果你需要經常處理大量的數據，索引視圖可以降低成本。

在另一方面，如果你有非常相似（如StackOverflow的情況下，上述的例子）兩個內容類型，你可以將它們組合起來得到一些優勢轉化爲一個表：

簡單：您只需要對錶格進行編碼 - 如果正確（即兩種內容類型非常相似），這可以使您的代碼庫變得更小，更簡單。
可擴展性：如果第三個內容類型出現再次類似於前兩個，並且類似的方式與前兩個匹配的方式相同，則可以直接擴展表來存儲所有三種內容類型。
性能索引。如果最常見的獲取數據的方式是將兩種內容類型結合起來並按日期排序（比如說），這兩個內容類型通用的字段，那麼有兩個單獨的表必須重複UNIONed然後排序。將兩種內容類型組合在一個表中，可以讓您在日期字段中放置單個索引，從而實現更快的查詢（儘管請記住，您可以從索引視圖中獲得類似的好處）。

如果你有normalize rigorously，你將擁有一個數據庫，其中每個實體類型在數據庫中都有自己的表。但是，以各種方式進行非規範化（例如將一個表中的兩個實體類型組合在一起）可能會有好處，這可能會（取決於數據的大小和形狀）超出成本。我建議至少在第一時間制定keeping all content types separate的策略，並考慮將它們組合爲tactical denormalization，如果事實證明是必要的話。

來源

2010-02-08 19:43:14

您需要閱讀一本關於使用PHP和MySQL構建網站的書。對於谷歌來說，這是一個很好的態度，因爲一些程序員認爲這是一個懶惰的問題。我建議閱讀「學習PHP MySQL和JavaScript」。無論如何，在你開始編寫你的網站之前，你需要計劃你將存儲什麼樣的信息，然後設計你的數據庫。說一個註冊表格將包含A First_Name，Second_Name，DateOfBirth，Country，Gender和Email。你創建一個名爲say「USER_INFO」的表，並且爲你想要存儲的數據分配一個數據類型，一個數字，文本，日期等等，然後通過PHP連接到MySQL並存儲或檢索你想要的數據。你真的需要閱讀一本書或一個教程，以便得到一個完整的答案，並且GOOGLE：P

來源

2011-04-03 08:28:38

瞭解大型mysql數據關係

回答

相關問題