我們正在創建一個數據庫，我們存儲大量記錄。我們估計在一個表中有數百萬（數十億年後）的記錄，我們總是插入並且很少更新或刪除任何記錄。它是一種我們每天插入歷史記錄的檔案系統。我們會生成不同的排序對用戶請求的這一歷史性的記錄報告，以便我們已經有些擔憂，並要求從你的人的技術輸入：大量數據庫
什麼是管理這種表和數據庫的最好方法？
如果您打算存儲數十億條記錄，那麼您將需要大量磁盤空間，我建議運行SQL 2008 R2的64位操作系統以及儘可能多的RAM和HD空間。根據你需要的性能，我會試圖研究SSD。
對於我們未來可能會看到的非常大的表格有什麼影響？
如果您擁有合適的硬件，並且具有正確索引的表格並正確標準化，那麼您應該注意到的唯一情況是報告將開始運行較慢。隨着索引文件變大，插入可能會稍微減慢，您只需要留意它。
對一張表格或表格大小的記錄數量是否有限制？
在上面描述的正確設置，沒有。它僅受磁盤空間限制。
我們如何設想從不同來源插入批量記錄（大部分來自Excel工作表）？
我遇到了運行大量SQL查詢的問題，但我從來沒有嘗試從非常大的平面文件導入。
索引大數據表的最佳方法是什麼？
根據需要索引爲少量字段並僅將它們保留在數字字段中。
我們應該在這個項目中使用哪種最好的ORM（對象關係映射）？
對不起，不建議這裏。
「幾年」中的數十億行不是特別大的卷。 SQL Server應該完全適應它 - 假設你的設計和實現是合適的。表格的大小沒有特別的限制。堅持堅實的設計原則：對錶格進行規範化處理，仔細選擇鍵和數據類型，並有適當的分區和索引策略。
你最後的聲明總結了它。沒有ORM可以很好地處理這些數據和報告查詢：使用SQL專家爲您提供幫助。你先在這裏聽到了。
否則
一些這些數據是基於我們在30個月內通過我們的一個系統獲得的約100億行數據的經驗，峯值爲40k行+每秒。
也爲高容量系統顯示方式：10 lessons from 35K tps
總結：做正確或者根本沒有...
當然，如果你打算有一個高容量的系統，聘請專家來設計它。 – HLGEM 2011-06-01 18:04:12
在一個職位有很多的問題 - 而且並非所有與「大容量數據庫」 - 你會很好地將其中的一部分分離出來並提供更多信息。 – 2011-06-01 06:24:14
因[dba.se]（http://dba.stackexchange.com/q/3074/630）過於寬泛，已關閉 – gbn 2011-06-01 06:58:56
您需要的是一位數據庫專家，最好擁有至少十年以上的高級經驗體積系統。 – HLGEM 2011-06-01 18:05:28