2

このアプリケーションの場合、スタッフは各曜日の開始と終了時にセットアップできる必要があります。オプションで、1、2、または 4 週間ごとにその開始/終了を繰り返すことができます。たとえば、毎週月曜日は午前 9 時に仕事を開始し、午後 2 時に終了します。そのような単純な繰り返しでは、3 つ、おそらく 2 つのモデル (非正規化用) を持つことを考えています。

Event
  - start: datetime
  - end: datetime
  - type: int (appointment, time off, cancelled, etc)
  - date: date (useful?)
  - staff_id: int
  - customer_id: int
  (more, redacted)

DayTemplate
  - active_start: datetime
  - active_end: datetime
  - staff_id: int

Day
  - weekday: int
  - start: datetime
  - end: datetime
  - recurrence: int (0: none, 1: once/mo, 2: other week, 4: every week)
  - day_template_id: int

パラメータが設定されたので、顧客は空いているときにスタッフを予約することができます (特定のチャンクで、たとえば午前 9 時、午前 10 時 15 分、午前 11 時 30 分など、休憩を設定できるようにするため)。スケジュールの任意の日について、そのスタッフ メンバーがアクティブな DayTemplate を簡単に照会できます。スタッフは、イベントを「休暇」として予約することでスケジュールをさらに微調整し、微調整を行うことができます。さらに、私は Day を DayTemplate に非正規化することを考えていました - 見栄えが悪いことはわかっていますが、スキーマは決して変更されず、パフォーマンス上の利点はそれだけの価値がありますか? これは十分な柔軟性ですか？

フィードバックに感謝します。これをレールで構築します。

4

1 に答える 1

1

このアプリケーションの場合、スタッフは各曜日の開始と終了時にセットアップできる必要があります。オプションで、開始/終了を 1、2、または 4 週間ごとに繰り返すことができます。たとえば、毎週月曜日は午前 9 時に仕事を開始し、午後 2 時に終了します。そのような単純な繰り返しでは、3 つ、おそらく 2 つのモデル (非正規化用) を持つことを考えています。

まだ非正規化しないでください。ビジネス ルールを理解することに集中し、それをレール内のビジネス オブジェクトにマッピングします。スキーマの設計は、特定のアプリの要件に基づいて行われます。

さらに、私は Day を DayTemplate に非正規化することを考えていました - 見栄えが悪いことはわかっていますが、スキーマは決して変更されず、パフォーマンス上の利点はそれだけの価値がありますか?

確かに、この時点でパフォーマンスの最適化について心配する必要はありません。代わりに、明快さと単純さのために最適化してください。パフォーマンスの最適化が必要なアプリの側面は、事前に推測していたものとはまったく異なる可能性があります。

これは十分な柔軟性ですか？

多すぎるかもしれません。最小限の受け入れ基準を満たす、可能な限り単純なものを作成することをお勧めします。どのような種類の柔軟性が必要になるかを事前に推測するのは非常に困難です。時間が経つにつれて、これらの「いつか必要になるかもしれない」機能をすべて維持するコストは、実際のユーザーが実際に必要とするものを構築する妨げになります。直感に反しますが、可能な限りシンプルに保つことが、最終的に非常に機能豊富なシステムを実現するための最良の方法です。配信速度を最適化し、実際のユーザーの手に渡して、フィードバックの収集を開始します。

また、あらゆる種類のスケジューリング システムを構築する場合、複雑さがすぐに手に負えなくなります。演習としてこれを行っている場合は、自分でコーディングしてみる価値があるかもしれませんが、これが本当に真剣に行う必要がある場合は、定期的なイベントのモデリング/スケジューリングを支援するために設計された多くの ruby​​ gem の 1 つを使用することを検討してください。個人的にはアイスキューブを使ったことがありますが、ルビーのツールボックスにはたくさんの選択肢があります

于 2013-01-24T05:12:24.443 に答える