16

Martin Fowler は、ここで繰り返しタスクのスケジューリングのための洗練されたオブジェクト モデルを定義しています。これは、OO コードに非常にうまく対応しています。ただし、永続化のためにこれをリレーショナル データベース スキーマにマッピングするのは難しい作業です。

特に11ページの画像で、彼が説明するすべての機能をカプセル化するスキーマとSQLの組み合わせを誰かが提案できますか.交差と結合はかなり明白です-複雑さは、可変パラメータを取り、解釈する必要がある「時間式」を表すことにあります.それらを組み合わせて「時間セット」にします。

明確にするために、リレーショナル データベースで定期的なイベントの概念を表す方法は多数あります。この特定のモデルをどのようにマッピングするかについて、皆さんに意見を求めたいと思います。

いくつかの可能なオプション:

  • 引数の数と使用を定義する「メタ」テーブル。醜いですが、おそらく動作します。ただし、'Temporal Expression' フォームの数は限られている可能性が高いため、これが提供する極端な柔軟性はおそらく多すぎます。
  • Postgres (およびおそらくその他の) RBMS でサポートされている、何らかの形式のテーブル継承。

パラメータリストをシリアル化し、結果を varchar() に保存することは、その方法がセットベースのクエリを防ぐため、解決策ではありません:)

4

2 に答える 2

27

この答えは多くの参照とほとんど実用的なコードではないのではないかと思います。最後にこれを台無しにしてからしばらく経ちましたが...

ここで混合したい2つのテクノロジーは、「アクティブデータベース」「時制データベース」だと思います。

1つ目はルールなどの評価に役立ち、2つ目は時間データを保存して特定のレコードが有効になったときに評価するのに役立ちます。これらはどちらもかなり大きな研究分野ですが、一時的な作業のほとんどはプレーンSQLで実行できます(データベースに十分な時間サポートがある場合)。SQLではアクティブな部分は難しいですが、PostgreSQLには少なくともこれをわずかに支援するルールがあります。他のデータベースについてはわかりませんが、それらのほとんどには、探しているものに変換できるルール/トリガー/制約のサポートがあります。

アクティブデータベースは、ルールを使用して格納するファクトの変更に対応できるデータベースです。これらのルールは実装固有の言語で指定されていますが、毎日のディスカッションでは、イベント-条件-アクションルール(ECAルール)が一般的です。アクティブデータベースシステムの概要については、アクティブデータベース管理システムのマニフェストアクティブデータベースシステムの記事をお読みください。ECAルールの詳細については、論理イベントとECAルール(ページは逆順o_0)およびアクティブオブジェクト指向データベースシステムのイベントを確認してください。

イベント処理は、複合イベントを処理し、それらのアクションを適切にトリガーする方法を処理するルール処理の特殊なケースです。これに関する興味深い読み物は、アクティブデータベースの複合イベント:複合イベント検出器のセマンティクス、コンテキスト、および検出と構造です。複合イベント処理サイトおよびイベントストリーム処理複合イベント処理のウィキペディアの記事も参照してください。

時制データベースは、時間、特に2つの特定の種類の時間を理解できるデータベースと見なすことができます。有効時間とトランザクション時間。レコードの有効時間は、そのレコードが有効である期間であり、レコードのトランザクション時間は、そのレコードがデータベースに存在する時間です。実用的な入門書として、SQLで時制データベースを作成する方法に関する本をお勧めします。RichardT。SnodgrassによるSQLでの時制データベースアプリケーションの開発

そうでなければ、時制データベースについて知りたいと思うかもしれないすべては、かなり包括的なドキュメントであるデータベースシステムのSpringer百科事典の時制データベースエントリで読むことができます(私は「時制データベース」エントリから始めます)が、始めるにはもう少し速く、閲覧と読み取りがかなり簡単な時制データベース用語集と、その出版物の部分にその地域で最も注目すべき出版物へのリンクがある(または持っていた...)サイトのタイムセンターをチェックしてください。

したがって、これについてすべて理解したので、11ページの画像を複合イベントとして表現でき、複合イベント検出器の適切な必要なサブセットを実装していれば、そのように検出/評価できることがすぐにわかります。残りは、時間的側面を持つテーブルのエントリとして表現できます:)

マーティン・ファウラーは、時間とともに変化するものについて、時間を扱う多くのパターンを要約したパターンで、この多くを自分自身で取り上げています。

結局、私はおそらく時間情報のデータベーススキーマを作成し、アクティブな部分にDBルールを使用するか、アプリケーションにその部分を実装します(ただし、ドラゴンは存在します)。PostgreSQLを使用する場合、ルールメカニズムはドキュメントのルールシステムの部分で説明されています。

読むべきことはたくさんありますが、これをすべて完全に理解すれば、あなたのプロの純資産はかなり上がる可能性があります:)

また、グーグルの良い用語は、「時制データベース」、「アクティブデータベース」、「ECAルール」です。

于 2008-11-23T13:42:53.280 に答える
2

SQL は、一連のデータを照会するための言語です。ドメイン固有の論理演算のエンコードを簡単にサポートすることはできません。つまり、「評価されるルール」は SQL のデータ型ではありません。これはオブジェクト指向の概念であり、データとロジックの両方がオブジェクト インスタンスのコンポーネントです。

したがって、SQL パラダイム内でできることのほとんどは、1 年の日付に対応する 365 行と、それぞれの日が繰り返しスケジュールの基準を満たすかどうかの true/false 値を格納することです。したがって、Fowler のモデルを実装する OO ロジックを使用して計算を行い、結果の 365 行を格納する必要があります。

次に、「今日 (または任意の日付) がスケジュールの一部かどうか」を知る必要がある場合。適切な行を検索し、true/false 列を確認するのは非常に簡単です。年間 365 行を格納することは、どのデータベースでも簡単です。

これはごまかしのように思えるかもしれませんが、私が言ったように、SQL はロジックではなくデータのセットに関するものです。

于 2008-11-22T08:06:01.650 に答える