【发布时间】：2015-05-07 15:16:30
【问题描述】：
我正在构建一个用于保存病历的 Web 应用程序。此应用程序的一项要求是记录患者数据的所有更改（查看、创建、更新、删除）以及系统中几乎所有其他有用信息（登录、cron 运行、数据导出等）。
我正在将数据存储到当前工作正常的数据库表中。然而，这张表很可能会很快变得不守规矩，并使数据库膨胀。我不允许删除日志条目。
我目前的计划是选择任意大小（例如 100 万个条目，大但仍可管理）。当表格达到 100 万个条目时，我会将 100,000 个最旧的条目移动到一个文件中，并将其存储到我们的文件服务器上。
有没有人对此问题有任何经验，对如何处理它有其他/更好的想法？
其他信息： 我主要担心的是不会从这些数据中删除任何内容。但是，数据不一定需要在几个月后访问。由于这些数据可以在几年内逻辑上达到 10 亿个条目（并且我有 300 个该数据库的副本，其中都包含此表），因此管理大小和性能的好方法是什么。这张表需要放在寻呼机上，当它突破 100 万时显然会成为一个问题，更不用说 10 亿了。
【问题讨论】：
-
你可能对Table Partitioning很熟悉！
-
如果 100 万个条目是“大”的，那么您需要看一下整体架构。许多 RDBMS 平台在数千万甚至数亿行的情况下运行良好。正如@PeterSchneider 所说，看看表分区，但这种关于什么是小型数据库的高级策略是值得怀疑的。
-
@PittsburghDBA 重点不在于 100 万个条目。关键是该表永远不会删除任何内容，并且会一直在增长。我只是在为永远不会删除数据的表寻找可扩展的解决方案。如果它能让我的观点更清楚，这张表可能会在几年内达到 10 亿或更多。
-
您的实际 DBMS 是什么？存储数十亿行是专门用于数据仓库的 DBMS 中的一项常见任务。但是无论如何你都需要一个更大的系统，这更昂贵......
-
@dnoeth 我目前正在使用 SQL Server，但可能会在表变得太大之前迁移到 MySQL。
标签： sql database-design