我遇到了一個問題，那就是我的大型數據庫需要很長時間訪問，部分原因是它的規範化並需要大量連接（它與啓動模式非常相似馬上）。但是，我不在乎寫入時間/潛在的寫入異常，並且需要數據庫快速進行分析有人可以請我指出適合分析的數據庫模式的良好文本，而不是那麼多的在線性能？以寫入訪問速度爲代價實現非常快的讀取訪問的數據庫模式
E.g.表格：1個表格具有靜態產品信息，表格2具有產品被購買/瀏覽過的所有時間的實例... ...確定在其上完成的動作，以及爲每個這樣的動作支付的成本。我的很多工作都涉及到某些產品的某些行爲已經完成。
謝謝。
保持原樣 - 即「正確」，但索引完全非規範化（即準備呈現）text search engine中的數據版本，例如lucene。
文本搜索引擎不提供更新或加入功能，但它們是FAST！你不會相信自己有多快，直到看到它，但它會在幾毫秒的順序。
文本搜索引擎是如此之快，因爲他們使用inverted index。我已經實施了幾次，總是非常值得。所有你需要做的就是確保每次你的真實數據發生變化時，你重新索引你的文本搜索引擎中的任何影響。
謝謝，的確是一個非常好的解決方案。將嘗試一下。但是，它不會考慮某些字段已排序的事實。此外，不要挑剔，絕對不會忘恩負義，但說幾毫秒而不說任何有關數據大小，查詢類型等的內容似乎並不正確！ 非常感謝您的回答。人們請保持答案的來臨。 – 0fnt 2012-02-09 20:05:09
另外，我有很多數字 - 雙打，它會打得好嗎？另外，你能否簡要地告訴我它如何比具有數字字段的數據庫更快地進行快速比較索引？ – 0fnt 2012-02-09 20:17:00
對於任何普通查詢，幾毫秒幾乎是標準響應時間。關於雙打，如果您使用的是java，請查看[solr]（http://lucene.apache.org/solr/） - 它是一個位於lucene之上的java層，它允許您保存和檢索基本的java類型田野。搜索可以基於所有數據類型的精確，部分和範圍。還有對經緯度區域搜索的直接支持。這真的很棒。 – Bohemian 2012-02-09 22:12:05
「正常化」並不總是意味着「需要大量連接」。但使用代理鍵（身份證號碼）通常確實。
構建一個測試數據庫，規範化爲5NF，而不使用具有自然鍵的任何事物的ID號。因此，例如，國家（使用ISO代碼），州，郵政編碼，類別等沒有ID號碼。
這種結構實現了空間/時間折衷。在某些情況下，在某些條件下，自然鍵的執行速度會快於替代物，因爲「關鍵」信息（咳嗽）通常在自然鍵中進行。所以你不需要一個連接去實現它。但是，代理鍵速度更快，因爲它們需要更少的I/O，更多的行將適合頁面。您需要測試以確定該點的位置，以及您是否可以忍受它。
有人會建議爲每個產品創建一個表，其中包含所有操作/數量？ – 0fnt 2012-02-09 20:07:56