使用年度数据设计数据库，每天更新

Question

所以我正在使用SQLITE在C＃中编写一个应用程序，它将跟踪我公司的销售数据。我们目前跟踪12个月（包括当前的）销售数据，并每天跟踪它。我打算能够及时比较两点（或更多）之间的销售数据，这是我迄今为止设计的数据库。它由两个表组成：

salesIndex是一个包含两列的表，一个唯一的id和一个表示时间戳的文本。这是一个主表，列出我们跟踪销售数据的所有时间。

salesData是一个包含7列的表，第一列是上一个表中的id，第二个是销售日期，接下来的5个是描述销售类型（即数量等）的整数。

我担心的是，如果我们每天每天都这样做，那么每年约有133,000个表，我们将数据存储3年，所以〜400k行，我想这会有点慢来自的数据。有没有更好的方法来为此设计数据库？我想也许我应该每天创建一个表来跟踪我们的销售情况，如果我们想要查看销售数天，我们只会查询每个表而不是一个巨大的表？任何帮助表示赞赏：）

Answer 1

请不要创建那么多表。你不仅会遇到维护困难，还会损害你的表现。

只需拥有一个包含正确标识行的销售表（在您的情况下可能意味着将date添加到主键）。假设您正确使用了索引，即使有400个百万行，性能也会很好，更不用说40万行了。

典型的索引实现为B-Tree，其高度（以及因此速度）在行数上取决于对数。实际上，这意味着即使在大量数据上，正确设计的索引也几乎可以即时工作。

Answer 2

我将salesData作为单个表，如果遇到性能问题（例如销售日期），只需根据需要使用索引

400,000行并不是那么多 - 你主要使用整数键，但即使每行长度为200字节，那仍然只有~75mb。

目前还不完全清楚销售数据的粒度是什么（即单行代表什么？）所以我假设每次销售只有一行。

将其保留为单个销售表的好处是可以根据计划的使用情况查询数据，但您也可以在其上运行您尚未想到的查询。设计数据库以满足特定查询解决了当前的技术问题，但很可能会再次困扰您：）

我认为多表格方法在满足您当前特定用例的方向上倾向太多，我认为除非您知道您将遇到严重不良的性能，否则最好在旁边犯错误有用性和灵活性。

希望这有帮助。

Answer 3

大多数现代数据库系统在从具有大量行的表中检索数据时没有太多问题，只要它们被正确编入索引。

您可以进行一些硬件调整。您可以确保您的数据库文件在raid 10集上，并且索引在raid 0集上（即非常快速的读取）。在数据库服务器中放入足够的内存。如果您有大量更新，则您的事务日志会转到与数据文件不同的磁盘（最好是不同的raid 10或至少是raid 1）。

除了硬件和索引调整之外，如果使用正确规范化的数据库，则不应仅出于性能原因而拆分表（甚至是数据库）。

实际执行此操作的唯一原因是您要归档数据并且不在生产中使用该归档数据，而只是作为只读数据库使用。 （例如报告）

希望这会有所帮助：）