我正在設計一個數據庫中的表，它將存儲來自應用程序的日誌條目。有幾件事讓我比平時更多地考慮這個設計。數據庫架構設計 - 提高存檔能力的技巧？
我當時的想法是讓他們寫活表/數據庫，然後使用ETL解決方案的舉動「老」條目的歸檔表/數據庫 - 這是巨大的，並在較慢的硬件。
我的問題是你知道的數據庫/表設計的任何提示，技巧或建議，以確保這項工作儘可能好？另外如果你認爲這是一個壞主意，請讓我知道，你認爲一個更好的主意會是什麼。
有些數據庫提供「分區」（例如Oracle）。分區就像一個視圖，它將幾個具有相同定義的表集合在一起。您可以定義將新數據分類到不同表格的標準（例如，月份或一年中的％6）。
從用戶的角度來看，這只是一個表。從數據庫PoV中，它是幾個獨立的表，因此您可以以有效的方式對它們運行完整的表命令（如截斷，刪除，從表（無條件），加載/轉儲等）。
如果你不能有一個分區，你會得到與視圖類似的效果。在這種情況下，您可以在單個視圖中收集多個表格，並重新定義此視圖，例如每月一次，從其餘的舊數據中「釋放」一張表格。現在，您可以高效地歸檔該表格，清理該表格，並在大型工作完成後再將其附加到視圖中。這應該有助於提高性能。
[編輯] SQL server 2005以上（企業版）支持分區。感謝Mitch Wheat
大表快速減速，使用ETL從大表中提取基於日期的數據，然後刪除舊行，這是一個很大的性能開銷。答案是使用多個表格 - 根據您的數據可能會有1個表格/月份。當然，你需要一些邏輯來在查詢中生成表名。
我同意使用觸發器填充'CurrentMonthAudit'表，在月末，您可以將該表重命名爲MonthAuditYYYYMM。使用ETL將舊錶移出主服務器將很容易，並且每個表都可以管理。相信我，這比試圖管理大約250M行的單個表格要好得多。
你的第一個很好的決定是儘可能保持簡單。
我已經有了一個簡單的只寫事務日誌文件的模式，其中的記錄只是按時間順序排列好運。然後你有幾個選項來切換老化的數據。即使每月有不同的表格，只要您牢記簡單，就可以在查詢方面進行管理。如果您在操作中有任何類型的複製，則可以將複製的表推出並用作存檔。然後從每個月的第一天開始新鮮的空表。
正常情況下，我會對這樣做的關係設計後果感到不安，但我發現只寫時間順序的日誌表是通常設計模式的例外，因爲您在這裏處理的原因。
但遠離觸發器。越遠越好。最簡單的解決方案是您正在討論的類型的主表，並具有簡單可靠的現成的時間驗證複製機制。
（順便說一句 - 大表不迅速減速，如果他們都經過精心設計的 - 他們慢下來慢。）
如果您不需要搜索最近的日誌記錄，還有另一種選擇：不要根本不使用數據庫。相反，將日誌信息寫入文件並每晚旋轉文件名。當文件被寫入後，您可以啓動後臺作業，將數據直接導入存檔數據庫。
數據庫不用永遠是最好的選擇，尤其是對日誌文件:)
SQL Server還支持分區表 – 2009-01-28 11:01:20
我應該說SQL服務器2005年起（企業版） – 2009-01-28 11:21:22