爲大型數據集創建MySQL數據庫模式

Question

我正在努力尋找構建適用於我的項目的結構的最佳方式。答案可能很簡單，但由於大量的列或表，這取決於它的設置。

我們有幾種工具，每種工具都可以爲許多客戶運行。每個工具都有一系列填充答案數據庫的問題。工具運行後，我們填充另一系列數據，即工具的輸出。我們有大約10個工具，全部填充1500個數據點的電子表格。這是我奮鬥的地方......每個工具都可以運行多次，許多工具共享相同的數據點。我的下一個項目是構建一個可以開始工具數據輸入的應用程序，但允許導入與已經運行的工具共享相同數據點的數據。

一個簡單的例子： 工具1 - 公司，numberofusers，numberoflocations，成本 工具2 - 公司，numberofusers，的TotalStorage，employeepayrate

因此，如果在同一家公司完成的工具1，我需要能夠填充「numberofusers」（或提供填充）當它們完成工具2時，因爲它已經存在。

我認爲最好是創建一個具有1500個表格的結構，每個數據元素包含1個數據元素，每個數據元素周圍都有附加數據，或者創建一個巨大的表格 - 比如。 ..

的customerID（FK），事件ID（FK），ToolID（FK），numberofusers，numberoflocations，成本，總的存儲，員工工資，.....（1500）

如果我走這條路並有一張大桌子我不知道這將如何影響性能。同樣，維持1500張桌子的難度也是如此。

另一個方面是，它可以很好地描述每個字段： numberofusers，title，description，active（bool）。我認爲這是唯一可能的，如果每個元素都在自己的表中？

想法？建議？對不起，冗長的問題，新的在這裏。

Answer 1

建立一個包含所有常見數據的主表：公司，＃用戶，..其他的東西。給每一行一個唯一的ID。

使用上面的公司ID爲每個唯一工具建立一個表格，以及該實施的唯一數據。爲每個表格提供「工具使用」和「公司」的主要（唯一鍵）。

這涵蓋了一個地方的常見數據，標識每個「客戶」，併爲每個客戶提供給定工具的多種用途。每個用戶和客戶都是可追蹤和獨特的。

更多關於normalization這裏。

Answer 2

我同意etherbubunny規範化，但對於較大的數據集，性能考慮很快變得重要。規範化數據庫中經常需要的連接才能顯示人類可讀的信息，因此即使是中等規模的表也需要性能殺手，這就是爲什麼很多數據倉庫模型使用非規範化數據集進行報告的原因。這主要是通過大量使用索引，歸檔和分區將聯合報告數據預先構建到新表中。

在許多情況下，智能使用分區本身也可以有效地幫助減少被查詢的數據集的大小。這通常需要相當多的維護，除非某些參數保持不變。

最後在你的情況下（和大多數人），我強烈建議你按照你能夠維護和理解正在發生的事情來構建它，然後通過慢查詢日誌，解釋和性能監視工具（例如percona's工具集。這會讓你深入瞭解真正發生的事情，併爲你提供一些數據返回這裏或MySQL論壇。我們總是可以在這裏進行推測，但最終真實的數據和您的設置將成爲您最適合的原動力。