数据库架构设计 - 提高归档能力的技巧？

Question

我正在数据库中设计一个表，用于存储来自应用程序的日志条目。有几件事让我比平时更多地思考这个设计。

• 但是，系统将在运行时使用这些日志条目来做出决策，因此需要相对快速地访问它们。
• 他们还有一个问题，那就是他们的数量会很多(我估计每月新增 1250 万)。
• 我最多不需要超过过去 30 到 45 天的时间来进行决策处理。
• 我需要将它们全部保存超过 45 天以用于支持和法律问题，可能至少需要 2 年。
• 表设计相当简单，都是简单类型(没有 blob 或任何东西)，在可能的情况下将使用数据库引擎放入默认数据，最多一个外键。
• 如果有任何不同，数据库将是 Microsoft SQL Server 2005。

我在想的是将它们写入实时表/数据库，然后使用 ETL 解决方案将“旧”条目移动到存档表/数据库 - 这很大而且硬件速度较慢。

我的问题是，您是否知道有关数据库/表设计的任何提示、技巧或建议，以确保其尽可能好地工作？另外，如果您认为这是个坏主意，请告诉我，以及您认为更好的主意是什么。

Answer 1

一些数据库提供“分区”(例如 Oracle)。分区就像一个 View ，它将具有相同定义的多个表收集到一个表中。您可以定义将新数据分类到不同表中的条件(例如，月份或星期 % 6)。

从用户的角度来看，这只是一张表。从数据库 PoV 来看，它是几个独立的表，因此您可以高效地对它们运行完整的表命令(如截断、删除、从表中删除(无条件)、加载/转储等)。

如果你不能有一个分区，你会得到与 View 类似的效果。在这种情况下，您可以在单个 View 中收集多个表并重新定义此 View ，例如，每月一次以从其余表中“释放”一个包含旧数据的表。现在，您可以有效地归档此表，清除它并在完成大工作后将其再次附加到 View 。这应该对提高性能有很大帮助。

[编辑] SQL Server 2005 及以后版本(企业版)支持分区。感谢Mitch Wheat