0

私は 24 時間の週単位のスケジュールを保存しています。つまり、各人は 24x7 の 2D 配列 ( availability[time][day]) を持ち、1 人あたり合計 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)     |
+---------+----------------+

選択の例 (各ユーザーは、実際には 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 テーブルの 1 つのフィールドに保存すると (例: users.availability)、パフォーマンスが向上しますか? (より多くの解析がありますが、大規模な結合はスキップされます)

  2. テーブルのサイズは本当に問題ですか？これは初めての大規模なアプリケーションなので、このテーブルが実際に心配するほど大きいかどうかはわかりません。(たとえば、25 人のユーザーが返された場合、availabilityテーブルには 4,800 のフィールドが含まれます [を含まないuser_id])

4

1 に答える 1

1

数千万行に近づいたときにのみ、パフォーマンスについて心配する必要があります。あなたの側の少し時期尚早な最適化を除いて、ここでは何の問題も見られません:)

あなたはすでに順調にスタートしているので、標準化されたルートに進むことで、パフォーマンスはまだあまり気にする必要がないようです。スケジュールを配列にシリアライズするのは、あまりにも不必要な作業です:

例: Y 日の X 時間に予定されているすべてのユーザーを検索したい場合はどうしますか? 配列に格納されている場合は、すべての行を解析し、時刻と日付を個別に検索する必要があります。振り出しに戻り、パフォーマンスに関する重大な懸念に対処することになります。

置く

EXPLAIN EXTENDED

クエリの前に、舞台裏で何が起こっているかを確認してください。結合がインデックスで行を検索している限り、アプリは問題なく動作します。

于 2012-12-29T00:19:28.260 に答える