我在學習mysql，並且正在爲工作而開發數據庫。一切都很好，但我有一個問題。我正在組織財務報表（資產負債表，收益表，現金流量表等），大多數公司都有季度報表（未經審計）和年度報表（已審計）。現在，對於每項聲明，我都有一個標記爲年度或季度的專欄。更適合基於內容或視圖創建表格嗎？
其他人不可能同時對經審計和未經審計的報表進行報告，所以我在考慮是否值得爲審計報表創建一個報表，以及未經審計的報表。我之所以想這是因爲數據最終會變得相當大，我認爲表格越小表現越快。
所以，當我在設計數據庫，我應該在設計基於內容（即。這就是同組的一切，無論），還是應該我來分組基於人們將如何訪問呢？
另一個問題便是，我應該通過countries..since下來我們堅定分組財務報表中所有的分析在90％同一國家
這是不可能在不知道整個問題的情況下明確回答的。
但是，通常需要單個表來表示系統中的每個邏輯實體。從它的聲音來看，季度和年度報表代表了相同的邏輯實體，但因單個類別欄/欄位而異。國家問題也是如此 - 如果唯一的區別是國家（一個分類），那麼他們可能應該全部存儲在同一個表格中。
如果你是按類別劃分資料單獨的表，您的數據將被分散在多個表，並且將很難查詢。例如，如果您想要統計系統中的所有語句，則必須查詢所有國家/地區表並將結果添加到一起。
編輯： Joe Celko稱這種反模式爲「Attribute Splitting」。
首先我要指出的範圍內，我不一位專業數據庫設計師 但是，如果我是你，在這種情況下，我會創建一個表，因爲實體基本相同。
如果你擔心MySQL的啤酒上的數據集服務表現的，也許這將是更好地開始建立在Postgres的你的應用程序。如果你需要運行復雜的查詢，你可以使用存儲的函數/過程來提升mysql的性能，當然你也可以使用memcache或者任何nosql的東西來讓SQL休息一下。
如果您確定用戶將主要僅搜索這種或那種類型的記錄，則可以構建三個表。其中一項爲所有記錄，其中一項爲經審計和未經審計的記錄。你可以讓它們與InnoDB的觸發器同步（ON UPDATE/DELETE/INSERT）。他們可以像意見一樣工作，但我認爲（未測試）他們會比觀點更快。在這種情況下，您必須只管理第一個「大」表。如果你插入一個審計記錄，觸發器觸發，並把記錄到審計表中等等......
最良好的祝願！
我同意Phil和Damien--一張桌子更好。你想要的是一張類型的真正的商業事物。如果您設計的表格與真實的東西相似，即使是抽象的或概念性的東西，那麼您的數據設計也更有可能經受住時間的考驗。一旦基於真實的數據描繪了一個模式，那麼你可以回過頭來應用規範化規則來形式化你的設計。
作爲一項規則，設計一個您擔心的性能問題是一個壞主意，但實際上並沒有看到。你對大表慢的直覺可能實際上是錯誤的。大多數DBMS系統像大表一樣，至少在某一點上。當表格很大時，查詢優化器選擇使用索引。當表格很小時，它們最終會得到全表掃描，這可能會降低併發訪問速度。如果你的表變得如此之大以至於超出了你的數據庫管理系統的能力，那麼就該考慮將你不再使用的舊數據歸檔或者購買一個更具可擴展性的數據庫管理系統。
感謝菲爾，我想你明白我的問題。也許我的問題更關係到mysql如何索引和搜索，但是會影響數據庫效果性能的大小？例如，如果我搜索所有加拿大公司的平均季度收入（並且此數據庫包含所有其他國家/地區的許多行以及年/季度數據），那麼查詢速度會很慢，因爲它必須經過大量不相關的數據？ – Lostsoul 2011-05-05 21:11:21
在任何現代RDBMS中，設計合理的表可以處理數百萬（如果不是數十億）行，如果它甚至在中途體面的硬件上運行（並且被正確索引等）。除非你正在談論一個非常龐大的數據集，否則我不會關心性能（甚至在我按類別分割數據之前，我會尋找其他選項）。 – 2011-05-05 22:00:26