1

私たちは、人々への支払いを処理するデータベースを開発しています。私が現在注目している分野は、予定された支払いオプションです。基本的に、このシステムは 2 週間に 1 回人々に支払いを送ります。したがって、14 日ごとの特定の日 (現時点では水曜日) に、システムは支払いを処理して送信する必要があります。

では、例を。PersonA は 1 日あたり 10 ドルを受け取ります。2 週間ごとに、システムは個人のすべての支払いを集計し、それらを合計して、支払いを送信します。

したがって、最初の支払いの後、その人は 140 ドルを受け取ります。

ただし、支払い日が祝日やクリスマス休暇期間（12月24日～1月2日）などの休業期間にあたる場合、システムは支払いの前日に支払いを行わなければならないため、複雑です。祝日、または閉鎖期間、およびその期間の将来の支払いを処理します。

例：

支払い期間は6月1日から6月14日までです。この期間の支払いは 14 日に送金され、その期間のすべての支払いの累積になります。ただし、10日から18日までは会社休業期間があります。したがって、9 日に、システムは 1 日から 14 日までのすべての支払いを取得し (これらの支払いの構築は処理されました)、9 日に支払いを作成する必要があります。次の期間（15日～29日）は通常通りの勤務となります。

問題は、この支払いスケジュールの処理です。すべての期間を含むスケジュール表を作成することが提案されています。したがって、1 つ記録します: 開始日 = 6 月 1 日、終了日、6 月 14 日。レコード 2 は 15 日の開始、29 日の終了などです。未来はどこまで行く？わかりません。しかし...それは私には奇妙に思えます。「発効日」が 6 月 1 日で、「期間」が「2 週間」などの 1 つのスケジュール行だけが必要であると考えました。次に、.Net または SQL を使用して、「トリガー」日かどうかを判断できます。したがって、最初のトリガー日は発効日に 14 日を加えた日付になります。その後、水曜日から月曜日に変更することにした場合 (たとえば)、スケジュールがアクティブになる月曜日の日付と、システムの日付がその日付に達したときに、新しいスケジュール行を追加します。新しいスケジュールがアクティブになります。これを処理するには何らかのロジックが必要ですが、予定日の 1 つの行の基本概念は私の考えです。将来のすべての 2 週間の日付を保持するのは奇妙に思えます。

閉鎖期間の処理は、'Exception Dates' タイプ テーブルを介して処理されます。これは単に祝日と閉鎖期間を保持するもので、基本的に支払いを処理できない日付です。

したがって、毎晩、プロセスが実行されます。そして、アクティブなスケジュールの行を取得し、その発効日と一致する 2 週間の日付であるかどうか (どのように?) を判断し、早期支払いをトリガーする必要があるかどうかを判断するために例外テーブルをチェックします。

発効日に基づいて支払い日を設定している場合、「期間」を確認するのは難しいかもしれません...しかし、将来のすべての2週間を確実に保存するのは間違っていますか?

これが私がやりたいことの基本的な始まりです..しかし...要件を処理できるかどうかはわかりません：

このテーブルは、スケジュールの行を保持します。変更があるたびに、新しい行が追加されます。

CREATE TABLE [dbo].[PaymentSchedule] (
    [PaymentScheduleId] INT  IDENTITY (1, 1) NOT NULL,
    [EffectiveDate]     DATE NOT NULL,
    [EffectiveDays]     INT  NOT NULL,
    CONSTRAINT [pk_PaymentSchedule] PRIMARY KEY CLUSTERED ([PaymentScheduleId] ASC)
);

このテーブルは、例外日を保持します。したがって、1 日は同じ開始日と終了日を持ちます... 範囲は​​異なる開始日と終了日を持ちます。

CREATE TABLE [dbo].[ExceptionDate]
(
    [ExceptionDateId] INT NOT NULL IDENTITY, 
    [StartDate] DATE NOT NULL, 
    [EndDate] DATE NOT NULL, 
    [Description] VARCHAR(50) NOT NULL, 
    CONSTRAINT [PK_ExceptionDate] PRIMARY KEY ([ExceptionDateId]) 
)

そして、これは、使用されたスケジュールにリンクされた支払いの履歴を保持できます。

CREATE TABLE [dbo].[PaymentScheduleHistory] (
    [PaymentScheduleHistoryId] INT IDENTITY (1, 1) NOT NULL,
    [PaymentScheduleId]        INT NOT NULL,
    CONSTRAINT [pk_PaymentScheduleHistory] PRIMARY KEY CLUSTERED ([PaymentScheduleHistoryId] ASC),
    CONSTRAINT [fk_PaymentScheduleHistory_PaymentSchedule] FOREIGN KEY ([PaymentScheduleId]) REFERENCES [dbo].[PaymentSchedule] ([PaymentScheduleId])
);

だから、これらの初期のテーブルのデザインに基づいて...私はそれを機能させる方法がわかりません. スケジュールに基づいて、今日の日付がトリガー日であるかどうかをどうにかして解決する必要があります。それが機能したら、例外日を管理する機能を追加できます。これは正しい軌道に乗っているように見えますか?

4

1 に答える 1

0

あなたの既存のデザインは私にはうまく見えます。

スケジュール期間の表を使用し、期間ごとに個別のレコードを使用することを検討する唯一の理由は、各期間の長さが事実上恣意的である場合です。スケジュール期間が一連のかなり単純なルールに従っていることを考えると、気にする必要はありません。

このようなテーブルを設定するもう 1 つの理由は、クエリを記述するたびにスケジュール期間の日付のルールを再コーディングする必要がない他のプログラマーの使いやすさのためです。これを回避する 1 つの方法は、そのようなテーブルをシミュレートするビューを作成することです。

于 2013-06-08T09:27:32.543 に答える