單個表格或單獨表格爲每個用戶保存相似的記錄？ （性能??）

Question

我有一個MySQL數據庫的2場景，我不知道該選擇哪一個，我已經遇到了幾個表的同樣的困境。

我正在製作一個只能由成員訪問的Web應用程序。每個成員都有自己的交易，費用，並說「列表」。記錄的標準在用戶中是相同的，但每個用戶可以有完全不同的記錄數量。

我的2個方案是我是否應該有一個表的交易，一個表的列表，一個表的費用......並在每個鏈接到特定用戶的主鍵的字段。或者...如果最好爲每個用戶分別創建交易表，費用表和列表表格（使用像「用戶」+交易或「用戶」+ exp這樣的組合字符串）。交易可以在1或2個用戶中使用，但費用和列表是完全獨立的。我將有一個主交易表來保存每筆交易的所有信息，但是有一個用戶交易表將主鍵鏈接到交易主鍵。

那麼，單獨的表格還是一張表格？如果有成千上萬的用戶擁有數百個交易/費用/列表......我只是不希望在很多交易或費用建立後查詢速度非常緩慢......沒有用戶永遠不需要查看任何內容其他用戶......嚴格只是他們的數據。

此外，我很熟悉數據庫是如何工作和存儲數據的，但我不是100％清楚。我只是希望它能夠快速工作，所以當用戶提交新的交易或費用時，我的另一個問題是（雖然它可能很愚蠢）......它是插入表的開始還是結束？或者它不相關...因爲在返回信息之前，查詢將以任何方式搜索表中的所有內容？

Answer 1

總是使用一張表來存儲一種實體。

或者更具體地說，你所說的是一個令人討厭的，複雜的優化，它在一個令人難以置信的小案例中起作用，這些案例幾乎肯定不是你的。

您只想爲一種條目使用一個表格。適當地索引它，並且當你不再需要它們時嘗試擺脫舊記錄。

此外，很多人的「大數據」的想法其實並不特別大。數據庫通常只需要很少的優化，而其數據仍然適用於RAM，在現代系統上這意味着32Gb。

Answer 2

關於你提到的第二個問題：

在MySQL的磁盤上記錄的順序是由您定義PRIMARY KEY。這意味着記錄不會在結尾或開始處插入，而是根據主鍵在何處進行插入。

在其他分貝的你必須要使用比PRIMARY另一個關鍵訂購磁盤上記錄使用CLUSTERED KEYS個選項，但這不是在MySQL的支持我的知識。

關於你提到的第一個問題：

，我發現自己在這個位置上幾次，最近我不斷收到回一個博客帖子（最後一組，得出的結論是在底部）：
http://weblogs.asp.net/manavi/archive/2011/01/03/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines.aspx

我引述：

在我們進入這個討論，我 要強調的是，沒有一個單一的 「最佳戰略擬合所有 方案「存在。正如你所看到的，這些方法的每一個都有其自身的優點和缺點。下面是一些 經驗法則來識別特定 情景 最佳策略：

• 如果你不需要多態關聯或疑問，向 TPC-換句話說，如果你從來沒有或瘦 很少查詢BillingDetails和 您沒有任何班級與BillingDetail基地 類關聯 。我推薦TPC（僅適用於Table of Concrete Type）（僅適用於 頂層級別 ），其中多態性通常不需要 ，並且在將來修改基類時不太可能。

• 如果您確實需要多態關聯或查詢， 子類申報相對較少 性能（特別是如果子類之間的主要區別 在 他們的行爲），身體向TPH（表每層次）。您的 的目標是最大限度地減少可空列的數量並使您自己（和您的DBA）確信 非規格化模式不會在長期運行中產生 問題。

• 如果您確實需要多態關聯或查詢， 子類申報許多特性 （子類主要是由不同的數據，他們持有 ），向TPT（每個類型表）瘦。或者， 取決於您的繼承層次結構的 的寬度和深度以及 聯接與聯合的可能成本， 使用TPC。

默認情況下，選擇TPH僅適用於簡單的 問題。對於更復雜的情況（或 ，當你被 建模者堅持 標準化的重要性 歸一化），你應該考慮 TPT策略。但在這一點上， 問自己是否可以不 更好地改造爲繼承對象模型中 代表團（代表團作出 組成強大的重用爲 傳承的一種方式）。複雜繼承是 通常最好避免各種與持久性無關的原因或 ORM。EF充當 域和關係模型之間的緩衝區，但是 並不意味着您可以在設計 類時忽略 持久性問題。