Question

我正在构建一个将使用mysql数据库的应用程序。在模式中，我有一个将在外部填充的数据表。采用与此类似的形式：

Item_id |  Name | Value  | Weekoftheyear

然后，我有另一个用户表，用于身份验证，注册等。部门分组的另一个表格。即，用户可以属于单个部门。在一年中的任何一周，项目只能属于某个部门的一个用户。

项目数量将保持大致相同（约700），但值将每周更改一次，这将导致上表中的新行。但是，部门/用户的数量将继续增加（取决于成功）。

我试图找出最好的方法来跟踪一个组中的哪个用户拥有一年中每个星期的哪个项目。我现在有这样的事情：

ID | Weekoftheyear |用户|项目

我担心的是，这会很快变得太大而且反应迟钝。每年有700件物品和52周。这意味着27个以上的用户意味着我会超过100万行。

是否有任何建议/最佳做法来处理此类事情。我想我不是第一个遇到这个问题的人，我不想重新发明轮子。或者它可能只是一个问题。

Answer 1

我认为你不应该担心一百万行。这就是数据库的用途。

通过正确的索引编制，您的查询都不必依赖于log（N）跳转。如果您记住索引被拆分为磁盘块，每个磁盘块在一个操作中读取，并且索引和数据都有大量的内存缓存，那么您的查询可能永远不会超过2个磁盘上有3个块。这需要几毫秒的时间，因此无需担心前期。

我最热烈的建议是不要担心早期的表现。只需选择最简单的设计，您所解释的这个方案就具有简单的功能。

稍后，当生产中的一年过去，并且您看到实际性能时，您可能会更改它。例如，您可以将表水平拆分为最近的数据和历史数据。然后调整查询以使用其中一个或两个。

该解决方案会使代码复杂化，然后只有在真正衡量性能损失时才会应用它。再一次，我不希望只有一百万行。

Answer 2

我担心的是，这会很快变得太大而且反应迟钝。每年有700件物品和52周。这意味着27个以上的用户意味着我会超过100万行。

别担心。测试

构建一个表，在其中填充一百万行并测试它是微不足道的。你应该能够在睡梦中做到这一点。可以把它想象成数据库设计者的五指练习。

正确设计和索引的表可能不会很慢。在一百万行的表中，PostgreSQL的响应时间小于0.2毫秒。

标准化是你的朋友。另请注意，一年中的几周肯定需要包括年份。