數據庫優化 - 每天存儲在不同的列中以減少行數

我正在編寫一個應用程序，它按用戶和日期存儲不同類型的記錄。這些記錄按類別劃分。數據庫優化 - 每天存儲在不同的列中以減少行數

在設計數據庫時，我們創建了一個表User，然後對於每種記錄類型，我們創建了一個表RecordType和一個表Record。

舉例：存儲與我們有以下表用戶事件數據：

Event   EventType 
-----   --------- 
UserId  Id 
EventTypeId Name 
Value 
Day

我們的老闆指出，（有一些原因），我們要去商店很多行（用戶的*天），並提出一個想法，似乎有點瘋狂的對我說：與一年中的每一天一列創建一個表，像這樣：

EventTypeId | UserId | Year | 1 | 2 | 3 | 4 | ... | 365 | 366

這樣，我們只需要每年每用戶1行，但我們會得到很大的排。由於大多數ORMs（我們正在爲這個項目使用rails3）使用select *來獲取數據庫記錄，我們不是在優化某些東西來「去優化」另一個嗎？

社區對此有何評論？

2012-01-23 dcarneiro

我認爲你老闆的想法不是最好的。每年的估計行數是多少？有什麼問題的數據庫引擎？ –

如果在同一天有兩次相同的事件會發生什麼？你有沒有計劃過一次事件發生的次數？ –

@CornelGhiban每個用戶每天約30行 – dcarneiro

這違反了第一範式。這是repeating groups across columns的一個例子。

爲什麼這是不好的例子：編寫一個查詢來查找給定事件發生在哪一天。您需要一個包含366個術語的WHERE子句，用OR分隔。這是枯燥乏味的寫作，而且無法索引。

即使您有很多行，關係數據庫也可以很好地工作。假設你有10000個用戶，平均每個用戶每天生成10個事件。 10年後，您將擁有10000 * 366 * 10 * 10行或366,000,000行。這是一個相當大的數據庫，但並不罕見。

如果您仔細設計索引以匹配針對此數據運行的查詢，您應該可以長時間保持良好性能。您還應該制定一個分區或歸檔舊數據的策略。

2012-01-23 17:07:30

我從來沒有處理過每桌有超過1,000,000行的數據庫，所以我不知道在性能方面會如何。我想我會堅持我的設計，並考慮我的老闆戰略，以存儲歷史操作的舊數據。 – dcarneiro

我經常使用每個表有數十或數百萬行的數據庫。 SQL Server很好地處理它。（顯然，少一些其他選項。）只要查詢和索引都精心完成，性能就不會開始下降，直到遠遠超過此值。 –

這打破了數據庫的正常形式的原則

如果你爲什麼不與你的事件表中的DateTime列有默認值（GetDate()我們所談論的SQL替換日列的適用）

然後你可以按日期分組...

2012-01-23 17:11:19

我不會這樣做。只要您花時間對錶格進行適當索引，數據庫服務器就可以很好地處理有很多行的表。如果它大大降低了數據庫的性能，我會首先確保你的查詢不會強制執行大量的全表掃描。

其他一些潛在的問題，我看到：

它可能會傷害ORM性能。
它會在路上產生可維護性問題。您可能不希望處理一年中每天都有366個字段的對象，因此可能需要大量的樣板膠水代碼才能跟蹤。
任何想要針對一系列日期進行搜索的查詢都將變得邪惡。
它可能會更浪費空間。這些行很大，您必須爲每個客戶創建的行數將是每個不同類型事件在一天內發生的最大次數的總和。除非所有這些事件發生的速度非常穩定和規律，否則這些行很可能是空的。

如果有的話，我建議基於其他列來分割表，而不是真的需要減小表的大小。也許通過UserId或一年？

2012-01-23 17:21:01

回答