我有一个计划的应用程序并从另一个数据库表中获取一些数据并转储到我的主应用程序数据库表中，该表中的记录数每天都会增加，我假设它会每天增长，因为它是发生的事务事件数据。该数据由主应用程序用于处理，该应用程序获取每条记录并进行所需的分析并将每条记录标记为已处理。
我可以提供什么样的解决方案，以便将来可以减小数据库的大小？
在这种情况下你会怎么做？
根据我对一些企业应用程序的观察，提供了一个选项，用户可以将“超过 60 天”等的记录归档到文本文件中。我可以提供一个选项，将处理过的记录归档到文本文件中，并且从数据库中删除记录，如果需要可以稍后导入文本文件？这是一个解决方案吗？
贵公司有什么样的过去数据报告需求？假设您将来不需要能够报告该数据，那么将归档数据放入文本文件是一件好事。但是，将其保存在文本文件中意味着您必须有一个手动过程，以便在需要时将其按需导入数据库。
更好的选择是将归档数据移至不用于事务处理 (OLTP) 的数据仓库数据库，而是用作分析处理数据库 (OLAP) 的基础。当需要报告这些归档数据时，就可以开始了。如果您仔细考虑如何在此归档数据库中构建数据，那么将所有数据聚合到一个 OLAP Cube 中应该非常容易，这使得报告这些数据的速度更快、更灵活。
但同样...取决于您是否报告数据，以及报告可能会回溯多长时间。
如果您偶尔需要访问旧数据，那么构建一个将其归档为文本然后从文本加载回来的过程可能不是一个很好的解决方案。硬盘很便宜。
您可以汇总旧数据。例如，如果事务数据现在是毫秒级的，但是当您报告较旧的数据时，您会按天获得它，然后考虑将数据聚合到“每日”作为您的归档过程。您可以每天将数十万行折叠成几行。
还要考虑一个好的分区方案，您可以将最近的事务保存在一组磁盘上，并将归档数据保存到其他磁盘上，希望在这个过程中您可以轻松地添加新磁盘并为这些磁盘创建表。
它确实取决于将对过去的数据进行多少分析，但是有一种方法可以将其全部保存在数据库中而不会成为性能问题。
想到的解决方案是对有问题的表进行分区。我的公司有一个数据库表，它的数据按月分区，每个表包含大约 2000 万行。分区使得使用这些数据比将其存储在单个表中更实用。现在唯一真正的限制是磁盘空间，考虑到现在它有多便宜，这不是问题。
但是，我知道有些数据库不支持分区。如果是这种情况，我认为将数据存储在分隔文件中将是一个合适的解决方案。
恕我直言，这取决于用户需要分析过去数据的可能性。如果可能，只需创建良好的索引并将所有数据保存在主数据库中。
如果不是，则将其放入 TXT。当然，它发生的时间必须是可配置的。