2

イベントを繰り返すアプリケーションがあります。したがって、イベントは、日ごとに「n 日ごと」、週ごとに「月/火/水/その他の n 週間ごと」、月ごとに「1 日、2 日、3 日などに n か月ごと」に繰り返すことができます。

テーブル設計の観点からこれを処理する最良の方法は何ですか? 2つの方法を考えることができますが、どちらが優れているかはわかりません。

1) 上記の 5 つの列、日のケースに 1 つ、週と月にそれぞれ 2 つの列。使用されていないものは null になります。私のアプリケーションでは、null が表示され、それらを無視することを選択できました。

2) 2 番目のテーブル (events_dateinfo など) を作成し、クエリで JOIN します。

オプション 2 はおそらくより「正規化」されているようですが、そうでないこともありますが、そのような単純なことに対してやり過ぎだと思いますか? また、オプション 2 に行く場合、行を列に変換する方法はありますか?つまり、特定のイベントの 2 週間の属性を選択し、それらを列として扱う方法はありますか?

4

2 に答える 2

1

正しいイベントに複数のスケジュールを含めることができることを理解していれば（これが、「行を列に変換する」必要がある理由です）。

この場合、2 つではなく 3 つのテーブルが必要になります。3 つ目はジャンクション テーブルでなければなりません。このスキームを使用すると、将来必要になった場合に新しいスケジュールを簡単に追加できます。したがって、次のようなものです。

table events (event_id, event_name, description)
table schedules (sch_id, schedule)
table event_schedule (event_id, sch_id)

私が知っているように、MySQL には PIVOT の可能性はありませんが、SELECT で GROUP_CONCAT() 関数を使用できます。イベントごとに 1 つの行になり、1 つのイベントのすべてのスケジュールが 1 つの列に表示されます。

SELECT e.event_name AS Event, GROUP_CONCAT( s.schedule SEPARATOR ', ') AS Schedule
         FROM events e 
    (LEFT) JOIN event_schedule es
    ON e.event_id = es.event_id
    JOIN schedules s
    ON s.sch_id = es. sch_id
         GROUP BY e.event_name;
于 2009-04-20T20:23:47.047 に答える
0

これを正規化して、あるテーブルのイベントと別のテーブルのイベントの繰り返しを処理したいと思います。

インデックスを適切な方法で処理すると、ビューを介してデータの要求を処理したり、データが大きくなった場合は、トリガーを使用した監査テーブルとして処理したりできます。

于 2009-04-20T14:40:30.210 に答える