设计具有年度数据的数据库，每天更新答案

【问题标题】：Designing a database with yearly data, updated daily设计具有年度数据的数据库，每天更新
【发布时间】：2012-02-01 09:05:05
【问题描述】：

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

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

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

我担心的是，如果我们每天每天都这样做，那么每年大约有 133k 表，并且我们会将数据存储 3 年，所以大约 400k 行，我想检索起来会有点慢数据来自。有没有更好的方法来为此设计数据库？我在想也许我应该每天创建一个表来跟踪我们的销售额，这样如果我们想查询几天的销售额，我们就只查询每个表而不是一个巨大的表？任何帮助表示赞赏:)

【问题讨论】：

您的意思是每年约 133k 行吗？ :)
并且每天重新创建一个表 - 我认为这对于除了最简单的查询（例如，“今年 1 月的销售额与去年相比如何？” 不会是编写简单的查询）。 salesData 不应该是您每天更新的单个表是否有原因？
我认为您的设计可以通过仅包含当天销售额的销售表来大大简化。然后您每年只需添加 365 1/4 行，您就可以快速运行查询以确定任何时间段的销售额。 12个月，6个月，今年的同一天，去年的同一天，甚至是过去X年的12个月定期销售额的比较……为每一天创建一个新表似乎有点过头了并且容易出现数据完整性问题。
您是否调查过是否已经有可用的软件包可以为您做到这一点？跟踪销售数据似乎是一个常见问题，市场上应该已经有很多解决方案了。

标签： c# .net database sqlite

【解决方案1】：

请不要创建那么多表。您不仅会遇到维护困难，还会影响性能。

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

一个典型的索引被实现为B-Tree，其高度（以及因此的速度）取决于行数对数。在实践中，这意味着设计合理的索引即使处理大量数据也几乎可以立即发挥作用。

【讨论】：

谢谢，我对数据库的来龙去脉不太熟悉，所以我不确定性能如何。我不能使用主键，因为销售表 ID 和日期会重复。为了简单起见，让我们看一下我们当前如何存储销售数据的 3 天。因此，如果我今天要存储我们的数据，我将包括今天、明天和后天，目前它在表格中看起来像这样：
Sorry..这个输入添加评论很烦人。基本上该表看起来像这里的 [link]pastebin.com/umctwAgg。无论哪种方式，表都将始终按 id 列排序，因为程序设计不允许在末尾以外的任何地方插入，并且也不会发生删除数据，所以从你所说的来看，我不必过多担心性能，谢谢你，先生。 :)

【解决方案2】：

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

400,000 行实际上并没有那么多 - 您主要使用整数键，但即使每行有 200 字节长，也只有 ~75mb。

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

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

我想说多表方法过于倾向于迎合您当前的特定用例，而且我认为除非您知道自己会遇到极其糟糕的性能，否则最好在一边犯错实用性和灵活性。

希望这会有所帮助。

【讨论】：

【解决方案3】：

只要索引正确，大多数现代数据库系统在从包含大量行的表中检索数据方面不会有太大问题。

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

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

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

希望这会有所帮助:)

【讨论】：

不要将索引放在 RAID 0（条带）上！！是的，您可以重新创建，但如果可靠性对您很重要（通常是），则不建议这样做。
米奇所说的同上。在数据方面 - 始终选择可靠性而不是性能。我会当场解雇任何在生产中这样做的人。
@MitchWheat 我同意可靠性通常具有更高的价值，尽管在某些情况下性能是一个问题。当可靠性是一个问题并且您不想面对停机时，确实要坚持容错。但如果性能是一个问题，这仍然是一个选择。
@Jeroen Landheer：这是个坏建议。不要这样做。