恣意的だが有限の容量のリレーショナルデータベースがあり、データベースは新しいイベントを常に生成しているオンラインシステムの履歴イベント情報を保持しているとします。データベースはレポートの目的でイベント情報を保持する必要がありますが、（N）日より古いイベントをパージする必要があります。イベントの発生率が比較的一定であり、時間の経過と共に増加または減少しないと推測するのに十分な履歴情報があれば、設計する最適なパーセンテージ（60％、70％、80％、...）このデータベースのために？もしそうなら、なぜあなたはその割合を選んだのですか？最適なデータベースの充実度？
です。
イベントの生成率は「比較的一定」と言われていますが、もう少し役に立つと思います。あなたは、統計的にも緊急にも、その率の不一致に対処するのに十分なマージンが必要です。あなたの履歴から得ることができる統計情報ですが、緊急事態はでしか推測できません。
実際の使用容量は、格納方法によって異なります。関連するノートでは、ある程度の膨らみを超えると、多くのファイルシステムが非常に遅くなります。この割合を合計マージンの一部として含めることをお勧めします。また、イベントパージの細分性なども考慮してください。頻度はどのくらいですか？
また、容量が足りなくなる結果を考慮してください。あなたのシステムはクラッシュしますか？システムの重要性は、とにかくどれくらいですか？スペースを増やすために緊急パージを行うことはできますか？停電の費用に比べて余分な容量はどれくらいの費用がかかりますか？
これは操作上の問題であるため、これはあまりデータベース設計の問題ではありません。
夜間のメンテナンスプロセス（または期限切れのデータを期限切れにする）では、合理的な毎日のイベントボリュームに十分な空き領域を確保する必要があります。たぶんスペースが足りなくなったことによる失敗はオプションではないでしょう。しかし、あなたは、あなたの毎日の量が何であるか、そしてその分散が何であるかを知ることによってどれくらいのスペースしか知りません。平均一日量が5,000,000件で、変動が+/- 4,000,000イベントで、標準偏差が2,000,000となっている場合は、同じ場合よりも多くの空き領域を確保する必要があります毎日の平均容量ですが、分散は+/- 500,000で標準偏差は50,000です。あなたに知らせる統計があるまで、あなたはただ推測しているだけです。
テラバイトのハードドライブのコストが200ドル未満の世界では、スペースに関する心配は価値がありません。
さらに重要なのは、IMHOは操作上の観点から、データとインデックスページを維持するための空き領域であり、挿入操作と更新操作のページ分割とそのパフォーマンスヒットを最小限に抑えることです。また、実際のデータについて知る必要があります。