Database design 最佳数据库完整性？

假设您有一个任意但容量有限的关系数据库，该数据库保存不断生成新事件的在线系统的历史事件信息。数据库应保存事件信息以便报告，但应清除早于（N）天的事件。假设您有足够的历史信息来推断事件生成率是相对恒定的，并且不会随着时间的推移而增加或减少，那么您是否会为此数据库设计一个最佳百分比（60%、70%、80%，…）？如果是这样，那么为什么选择这个百分比呢？

这与其说是一个数据库设计问题，不如说是一个操作问题

您的夜间维护过程（或者，不管您如何老化过期的数据）需要维护足够的可用空间来容纳任何合理的每日事件量。可能由于空间不足而导致的故障不是一个选项。但是你只有知道你每天的音量和变化量，才能知道你的空间有多大。如果你的平均日处理量为5000000个事件，方差为+/-4000000个事件，并且你的标准偏差为2000000，那么你将需要比同样的平均日处理量保持更多的自由空间，但方差为+/-500000，标准偏差为50000。在你得到一些统计数据之前，你只是在猜测

在一个TB级硬盘价格不到200美元的世界里，担心空间是不值得的

更重要的是，从操作的角度来看，IMHO就是要在数据和索引页上维护多少可用空间，以便最大限度地减少插入和更新操作中的页拆分以及由此带来的性能影响。同样，你需要知道一些关于实际数据的信息才能弄清楚这一点。

这取决于具体情况

好的，稍微有点帮助，你说事件生成的速率是“相对恒定的”。你需要足够的余地来处理这个比率中的不稳定因素，包括统计数据和紧急情况。你可以从你的历史中得到统计数据，但紧急情况只能猜测

实际使用的空间量取决于存储方式。与此相关的是，许多文件系统如果超过一定的满度，就会变得非常慢；您可能希望将此百分比作为总利润的一部分。同样，考虑一下事件清除的粒度：它经常发生吗？

<>也考虑能力耗尽的后果。你的系统会崩溃吗？无论如何，这个系统有多重要？你能做一次紧急清理来腾出更多的空间吗？相对于停机费用而言，额外容量的成本有多高