我在MySQL數(shù)據(jù)庫中存儲了各種用戶詳細信息。最初，它是在各種表中設置的，這意味著數(shù)據(jù)與UserId鏈接，并通過有時復雜的調用輸出，以根據(jù)需要顯示和操作數(shù)據(jù)。建立一個新系統(tǒng)，將所有這些表組合成一個大的相關內容表幾乎是有意義的。這將是幫助還是阻礙？調用，更新或搜索/操作時的速度考慮？這是我的一些表結構的示例：用戶-用戶ID，用戶名，電子郵件，加密的密碼，注冊日期，IPuser_details-Cookie數(shù)據(jù)，姓名，地址，聯(lián)系方式，從屬關系，人口統(tǒng)計數(shù)據(jù)user_activity-貢獻，最近一次在線訪問，最后一次查看user_settings-配置文件顯示設置user_interests-廣告可定位變量user_levels-訪問權限user_stats-匹配數(shù)編輯：到目前為止，我已經(jīng)對所有答案進行了投票，它們都有本質上可以回答我問題的元素。大多數(shù)表具有1：1的關系，這是使它們歸一化的主要原因。如果表格跨越100多個列，而這些單元格的大部分可能仍為空時，會不會有問題？
3 回答
慕雪6442864
TA貢獻1812條經(jīng)驗 獲得超5個贊
多個表以下列方式/案例提供幫助：
（a）如果不同的人要開發(fā)涉及不同表的應用程序，則將它們拆分是有意義的。
（b）如果您想為不同的人賦予不同的權限，以進行數(shù)據(jù)收集的不同部分，則拆分它們可能更為方便。（當然，您可以查看定義視圖并對其進行適當授權）。
（c）為了將數(shù)據(jù)移動到不同的地方，尤其是在開發(fā)過程中，使用表來減小文件大小可能是有意義的。
（d）在基于單個實體的特定數(shù)據(jù)收集開發(fā)應用程序時，較小的占地面積可能會給您帶來舒適感。
（e）這是一種可能性：您認為作為單個值的數(shù)據(jù)將來可能會變成真正的多個值。例如，信用額度到目前為止是單個值字段。但是明天，您可能會決定將值更改為（日期從，日期到，信用值）。拆分表現(xiàn)在可能會派上用場。
我的投票將是針對多個表-數(shù)據(jù)已適當拆分。
HUWWW
TA貢獻1874條經(jīng)驗 獲得超12個贊
合并表稱為非規(guī)范化。
可能會（或可能不會）使某些查詢（使很多JOINs）更快地運行，而以創(chuàng)建維護地獄為代價。
MySQL只能使用JOIN方法，即NESTED LOOPS。
這意味著對于驅動表中的每個記錄，MySQL在循環(huán)中在驅動表中找到匹配的記錄。
查找記錄是相當昂貴的操作，可能需要花費純記錄掃描數(shù)十倍的時間。
將所有記錄移到一個表中將幫助您擺脫此操作，但是表本身會變大，并且表掃描需要更長的時間。
如果其他表中有很多記錄，則表掃描的增加可能會增加按順序掃描記錄的好處。
另一方面，可以保證維護。
智慧大石
TA貢獻1946條經(jīng)驗 獲得超3個贊
他們都是1：1的關系嗎？我的意思是，如果某個用戶可以屬于不同的用戶級別，或者如果用戶興趣在用戶興趣表中表示為多個記錄，那么合并這些表將立即成為問題。
關于以前關于規(guī)范化的答案，必須說數(shù)據(jù)庫規(guī)范化規(guī)則完全忽略了性能，而只是在看什么是整潔的數(shù)據(jù)庫設計。這通常是您想要實現(xiàn)的目標，但是有時在追求性能方面積極地規(guī)范化是有意義的。
總而言之，我要說的問題歸結為表中有多少個字段，以及它們被訪問的頻率。如果用戶活動通常不是很有趣，那么出于性能和維護的原因，始終將其保留在同一記錄上可能會很麻煩。如果經(jīng)常訪問某些數(shù)據(jù)（例如設置），但僅包含太多字段，則合并表可能也不方便。如果僅對性能提高感興趣，則可以考慮其他方法，例如將設置分開，但將其保存在自己的會話變量中，這樣就不必經(jīng)常查詢數(shù)據(jù)庫。
添加回答
舉報
0/150
提交
取消