2
制約データベース
私は制約プログラミングの背後にある直感を知っているので、制約ソルバーを使用したプログラミングを実際に経験したことはありません。一貫性のあるデータとして定義することを達成できるようになるのは、別の状況だと思いますが。 環境： ETLサーバーに実装する一連のルールがあります。これらのルールは次のいずれかです。 一列に作用します。 行間、1つまたは異なるテーブルでの動作。 2つの実行間で同じように動作します（すべてのデータ、または最後のn回の実行に対して同じ制約を維持する必要があります）。 3番目のケースは、2番目のケースとは異なります。2番目のケースが成立するときに成立しますが、明確に定義された実行数の場合です。これは、1回の実行（1つのファイル）またはその間の（1からn（前の）またはすべてのファイル）に適用できます。 技術的にはETLを考案したため、2つの実行の間にメモリはありません：2つのファイル（ただし、これは再考されます） 3番目の種類のルールを適用するには、ETLにメモリが必要です（データをETLでバックアップすることになると思います）。または、ある時間枠の後でデータベース全体を無限に再チェック（ジョブ）することで、データベースに到達するデータは、必ずしも3番目の種類のルールを時間内に満たす必要はありません。 例： 継続的に流れるデータがありますが、制約されたデータベース全体に制約を適用します。翌日、たとえば1か月のバックアップまたは修正データを受け取ります。この時間枠では、これだけの制約が満たされるようにしたいと考えていますデータベース全体を気にせずに実行（この時間枠）。将来の実行では、過去のデータを気にせずにすべてのデータを以前と同様に制約する必要があります。時相論理に適合する他のルールを想像できます。 現時点では、最初の種類のルールのみが実装されています。私が考えた方法は、以前に基づいた一貫性を参照するフラグを使用してすべてのデータ（制約された列のみ、おそらくハッシュ値で）をバックアップする（あらゆる種類のMySQL、PostgreSQL、MongoDBなどの）縮小データベースを用意することです一種のルール。 質問：このプロセスを容易にする解決策/概念の代替案はありますか？ するために、説明クックプログラミング言語で、一連のルールと次のアクションの例： run1 : WHEN tableA.ID == tableB.ID AND tableA.column1 > tableB.column2 BACK-UP FLAG tableA.rule1 AFTER run1 : LOG ('WARN') run2 : WHEN tableA.column1 > 0 DO NOT BACK-UP FLAG tableA.rule2 AFTER run2 : LOG ('ERROR') 注：制約プログラミングは理論的には組み合わせ問題を解決するためのパラダイムですが、実際には問題の開発と実行を高速化できます。これは、制約を解決する問題とは異なると思います。最初の目的は解決前に制約を最適化することではないため、おそらくデータドメインを制限することもありません。主な関心事は、データ受信にルールを適用し、いくつかの基本的なアクションを実行することです（行の拒否、行の受け入れ、ロギング...）。 これが非常に広範な質問ではなく、これが正しい場所であることを本当に望みます。