0

我存储每周 24 小时的时间表，这意味着每个人都有一个 24x7 二维数组 ( availability[time][day])，每人总共 168 个元素。在通过用户进行搜索时，可用性是一个过滤器，这意味着这些元素必须存储在一个表中 ( availabilities)。

架构的一部分availabilities：

+---------+----------------+
| Field   | Type           |
+---------+----------------+
| user_id | int(10)        |
| time    | varchar(4)     |
| mon     | tinyint(1)     |
| tue     | tinyint(1)     |
| wed     | tinyint(1)     |
| thu     | tinyint(1)     |
| fri     | tinyint(1)     |
| sat     | tinyint(1)     |
| sun     | tinyint(1)     |
+---------+----------------+

示例选择（每个用户实际上一整天会有 24 行）：

+---------+------+-----+-----+-----+-----+-----+-----+-----+
| user_id | time | mon | tue | wed | thu | fri | sat | sun |
+---------+------+-----+-----+-----+-----+-----+-----+-----+
| 1       | 6am  |   1 |   0 |   1 |   1 |   1 |   0 |   0 |
| 1       | 7am  |   1 |   0 |   1 |   1 |   1 |   0 |   0 |
| 1       | 8am  |   1 |   0 |   1 |   0 |   1 |   0 |   0 |
| 1       | 9am  |   0 |   0 |   0 |   1 |   0 |   0 |   0 |
| 1       | 10am |   0 |   0 |   0 |   1 |   0 |   0 |   1 |
| 1       | 11am |   1 |   0 |   1 |   0 |   1 |   0 |   1 |
| 1       | 12pm |   1 |   0 |   1 |   1 |   1 |   0 |   1 |
+---------+------+-----+-----+-----+-----+-----+-----+-----+

我担心这个表会很大，加入和解析它会大大减慢速度。可用性过滤器将是最后一个应用的过滤器，但返回的潜在用户集可能仍然很大。

我的问题：

  1. 有没有更有效的方法来存储这些信息，这样表就不会那么大了？将数组序列化并将其保存到用户表上的一个字段（例如users.availability）有助于性能吗？（会有更多的解析，但会跳过大量的连接）

  2. 桌子的大小真的是个问题吗？这是我的第一个大型应用程序，所以我不确定这张表是否真的大到可以担心。（例如，如果返回 25 个用户，则该availability表将有 4,800 个字段 [不包括user_id]）

4

1 回答 1

1

当您接近数千万行时，您只需要开始担心性能。我在这里没有看到任何问题，除了你的一些过早的优化:)

由于您已经从正确的角度开始，看来，通过走规范化路线，性能不应该成为太多关注的问题。将时间表序列化为数组将是太多不必要的工作：

示例：如果您想搜索在 Y 天 X 小时安排的所有用户怎么办？如果将其存储在数组中，则必须单独解析和搜索每一行的时间和日期。您将回到原点并解决有关性能的严重问题。

放一个

EXPLAIN EXTENDED

在您查询之前查看幕后发生的事情。只要您的联接通过索引搜索行，您的应用程序就应该运行。

于 2012-12-29T00:19:28.260 回答