首頁猿問 MySQL：多個表還是一個包含許多...

MySQL：多個表還是一個包含許多列的表？

SQL Server MySQL

慕萊塢森 2019-12-13 09:28:45

因此，這更多是一個設(shè)計問題。我有一個主鍵（例如用戶的ID），并且有大量與該用戶相關(guān)聯(lián)的信息。我應(yīng)該根據(jù)信息將多個表細(xì)分為幾類，還是只有一個表包含許多列？我過去這樣做的方法是擁有多個表，例如，一個表用于應(yīng)用程序使用情況數(shù)據(jù)，一個表用于配置文件信息，一個表用于后端令牌等，以使事情看起來井井有條。最近有人告訴我，最好不要那樣做，有一個包含很多列的表也可以。關(guān)鍵是，所有這些列都具有相同的主鍵。我是數(shù)據(jù)庫設(shè)計的新手，所以哪種方法更好，優(yōu)缺點是什么？常規(guī)的做法是什么？

查看完整描述

3 回答

胡子哥哥

TA貢獻(xiàn)1825條經(jīng)驗獲得超6個贊

任何時候信息都是一對一的（每個用戶都有一個用戶名和密碼），那么最好在一個表中使用它，因為它減少了數(shù)據(jù)庫檢索結(jié)果所需的聯(lián)接數(shù)。我認(rèn)為某些數(shù)據(jù)庫對每個表的列數(shù)有限制，但是在正常情況下我不會擔(dān)心它，如果需要，您可以隨時將其拆分。

如果數(shù)據(jù)是一對多的（每個用戶有數(shù)千行使用情況信息），則應(yīng)將其拆分為單獨的表以減少重復(fù)的數(shù)據(jù)（重復(fù)的數(shù)據(jù)會浪費存儲空間，緩存空間，并使數(shù)據(jù)庫難以維護(hù)）。

您可能會發(fā)現(xiàn)有關(guān)數(shù)據(jù)庫規(guī)范化的Wikipedia文章很有趣，因為它深入討論了這樣做的原因：

數(shù)據(jù)庫規(guī)范化是組織關(guān)系數(shù)據(jù)庫的字段和表以最小化冗余和依賴性的過程。規(guī)范化通常涉及將大表劃分為較?。ê洼^少冗余）的表，并定義它們之間的關(guān)系。目的是隔離數(shù)據(jù)，以便可以僅在一個表中進(jìn)行字段的添加，刪除和修改，然后通過定義的關(guān)系傳播到數(shù)據(jù)庫的其余部分。

還需要注意非規(guī)范化，因為在某些情況下重復(fù)數(shù)據(jù)會更好（因為它減少了數(shù)據(jù)庫讀取數(shù)據(jù)時需要做的工作量）。我強烈建議您盡可能使數(shù)據(jù)規(guī)范化，以便開始使用，并且只有在您意識到特定查詢中的性能問題時才進(jìn)行非規(guī)范化。

反對回復(fù) 2019-12-13

Helenr

TA貢獻(xiàn)1780條經(jīng)驗獲得超4個贊

一個大桌子通常是一個糟糕的選擇。相關(guān)表是設(shè)計用于關(guān)系數(shù)據(jù)庫的對象。如果您正確地建立索引并且知道如何編寫性能查詢，它們將表現(xiàn)良好。

當(dāng)表中的列過多時，您可能會遇到數(shù)據(jù)庫在其上存儲信息的頁面實際大小的問題。記錄可能最終對于頁面而言太大，從而可能導(dǎo)致您最終無法創(chuàng)建或更新特定記錄而使用戶不滿意，或者您（至少在SQL Server中）可能因某些原因而溢出數(shù)據(jù)類型（如果要執(zhí)行此操作，則需要查找一組規(guī)則），但是如果許多記錄將使頁面大小溢出，則會造成嚴(yán)重的性能問題?，F(xiàn)在，MYSQL如何處理頁面以及潛在頁面大小過大時是否有問題，您需要在該數(shù)據(jù)庫的文檔中查找。

反對回復(fù) 2019-12-13

搖曳的薔薇

TA貢獻(xiàn)1793條經(jīng)驗獲得超6個贊

我有一個很好的例子。具有以下一組關(guān)系的過度標(biāo)準(zhǔn)化的數(shù)據(jù)庫：

people -> rel_p2staff -> staff

和

people -> rel_p2prosp -> prospects

在人員具有姓名和人員詳細(xì)信息的地方，人員僅具有人員記錄的詳細(xì)信息，潛在客戶僅具有潛在客戶的詳細(xì)信息，而rel表是關(guān)系表，其中包含來自與人員和潛在人員鏈接的人員的外鍵。

這種設(shè)計針對整個數(shù)據(jù)庫進(jìn)行。

現(xiàn)在要查詢這組關(guān)系，每次都是一個多表聯(lián)接，有時是8個或更多表聯(lián)接。到今年年中，它的運行情況一直很好，當(dāng)時它開始變得非常緩慢，現(xiàn)在我們已經(jīng)超過了40000條記錄。

索引和所有低落的成果已于去年用完，所有查詢都經(jīng)過優(yōu)化以達(dá)到完美。這是特定標(biāo)準(zhǔn)化設(shè)計的道路的盡頭，現(xiàn)在，管理人員批準(zhǔn)了對依賴于該應(yīng)用程序的整個應(yīng)用程序的重建以及數(shù)據(jù)庫的重建，歷時6個月。$$$$哎呀。

解決方案將是people -> staff與people -> prospect

反對回復(fù) 2019-12-13