我正在设计一个数据库中的表，它将存储来自应用程序的日志条目。有几件事让我比平时更多地考虑这个设计。数据库架构设计 - 提高存档能力的技巧？
我当时的想法是让他们写活表/数据库，然后使用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