問題タブ [transactional-database]

トランザクションデータベースを使用して、ユーザーフレンドリーなインターフェイスのundoプロパティを実装する方法がわかりません。

一方では、ここで回答に記載されているように、ユーザーにはマルチレベル（無限）の取り消しの可能性があることをお勧めします。この問題に役立つ可能性のあるパターンは、Memento またはCommandです。

ただし、トリガー、増え続けるシーケンス番号、元に戻せない手順などの複雑なデータベースを使用すると、トランザクションの境界とは異なるポイントで元に戻すアクションがどのように機能するかを想像するのは困難です。つまり、最後にコミットされたトランザクションが単なるロールバックである時点まで元に戻しますが、どのようにして別の瞬間に戻ることができますか？

更新（これまでの回答に基づく）：変更が既にコミットされているときに元に戻るが機能することを必ずしも望んでいません。トランザクションが開いている実行中のアプリケーションに焦点を合わせます。ユーザーが[保存]をクリックするたびにコミットを意味しますが、保存する前に（同じトランザクション中に）元に戻るが機能するはずです。データベースを永続層として使用することは単なる実装の詳細であり、ユーザーはそれを気にする必要がないことを私は知っています。しかし、「データベースとGUIで元に戻すという考え方は根本的に異なる」と考え、データベースで元に戻るを使用しない場合、無限の元に戻すは単なる流行語にすぎません。「ロールバックは...ユーザーによる取り消しではない」ことを私は知っています。

では、同じトランザクション内で「変更の結果としてのカスケード効果」を考慮して、クライアントレベルの取り消しを実装するにはどうすればよいでしょうか。

免責事項：スタックオーバーフローとインターネットの両方でスナップショットとバージョニングのトピックについて読むことができるすべてを読みました。私の要件は、監査証跡またはデータベースレベルのスナップショットのバージョン追跡ではありません。私は1週間以上を費やして、自分で調査し、可能な選択肢について考えました。申し訳ありませんが、いくつかのリンクを見逃している可能性があります-私の問題の解決策がすでに他のスレッドで議論されている場合は、そこに私を向けてください。

少し長いです。我慢してください。

状況は次のとおりです。トランザクションデータベースにトランザクションデータのスナップショットを保存し、参照データの改訂履歴を保持するための汎用設計を作成しようとしています。

ビジネスプロセスの一環として、ユーザーはボタンを押して特定のオブジェクトを公開できます。説明のために、ユーザーは交渉が始まる前にベンダーからの提案を公開できるとしましょう。次に、交渉プロセスのさまざまな時点で、ユーザーは提案データを公開できます。提案には、予算、販売目標、およびその他の多くの項目が含まれています。プロポーザルのスナップショットを作成するときは、リンクされているすべてのエンティティのスナップショットを作成する必要があります。最後に、交渉後、契約が締結されます。この時点で、契約の完全なスナップショットを作成する必要があります。契約内のすべてのエンティティがプロポーザルに含まれているわけではありません。重複するエンティティは多数ありますが、プロポーザルと契約に関連付けられている固有のエンティティがあります。

これらの公開バージョンと最新のアクティブバージョンの両方を利用可能にしておく必要があります。公開されたバージョンは、両方のベンダーと管理チームが参照できるようにWebサイトで入手できます。公開されたすべてのバージョンがWebサイトで利用できるわけではありませんが、最後に公開された提案と最新の公開された契約は常にWebサイトで利用できます。このWebサイトも、同じデータベースから作成する必要があります。

また、財務ユーザーは予算のみのスナップショットを作成することを決定でき、営業マネージャーは販売目標のスナップショットを作成できます。そのため、スナップショットは複数の粒度で利用できます。

また、マスターデータのバージョンを追跡する必要があります。主要なマスターデータ列へのすべての変更を経時的に追跡することはビジネス要件です。たとえば、販売目標に関連付けられた地域情報があります。地域の名前は変更される可能性があるため、これらの変更を追跡する必要があります。提案時に、リージョンの名前がR1であり、スナップショットが作成されていると仮定します。次に、リージョンの名前がR2に変更され、他の2つのスナップショットが作成されます。その時点での販売目標を正しい地域名にリンクできるようにしたいのですが、必ずしも最新の地域名にリンクする必要はありません。

トランザクションDBとデータウェアハウスDBの両方があるため、モデリングにある程度の柔軟性があり、この情報の一部をトランザクションDBまたはデータウェアハウスDBのいずれかに格納することを決定できます。

これが私たちのデザインです。公開されたデータに関する基本情報（誰が公開したか、日付、理由、公開されたオブジェクトのタイプ（提案、予算、または販売目標））をキャプチャする公開テーブルがあります。

スナップショットは元のデータと同じテーブルに保存されます。したがって、プロポーザルのスナップショットは、ライブプロポーザルとともにプロポーザルテーブルに保存されます。公開する必要のあるすべてのテーブルに、公開IDという列があります。この列は、PublicationテーブルへのFKです。パブリケーションIDがnullの場合、そのレコードはアクティブなバージョンです。

投稿が非常に長いことに気づきました。したがって、シナリオの詳細をリストするのではなく、マインドマップで設計上の考慮事項をすばやく要約することを考えました。

現在、私たちが傾倒している2つのソリューションがあります。どちらも、変更されたかどうかに関係なく、すべてのデータのスナップショットを保存します。テーブル構造をそのまま維持しながらデルタのみを維持するには、スナップショットオブジェクトの挿入/更新のたびに実行する必要がある非常に複雑なストアドプロシージャが必要になります。これには時間がかかり、ボリュームはとにかくそれほど大きくないので、私はこのルートを下りたくありません。

解決策1：オブジェクトが公開されるたびに（提案や予算など）、XMLツリーにデータを入力し、これをデータベースに保持します。最新バージョンのみがWebサイトで利用可能である必要があり、古いバージョンが必要になることはめったにありません。これを考えると、XMLを使用しているために大きなパフォーマンスの問題が発生しますか？SQLServerを使用しています。データ量はそれほど大きくありません。

解決策2：すべてのトランザクションテーブルにはパブリケーションIDがあり、参照データには開始日と終了日があります。オブジェクトが公開されるたびに、すべてのトランザクションレコードのコピーを作成し、そこに公開IDを配置し、すべての参照データレコードをコピーして、スナップショットの日付を終了日として配置します。これにより、公開プロセスの外部で参照データの通常のバージョン管理を行うことができます。

これらの2つのアプローチの欠点と、他にもっと良いシナリオがあるかどうかについて、ここで経験豊富な心からの意見が必要です。

これは、私の他の投稿の 1 つで heximal によって提起されたコメントのフォローアップです。deleted_onこの列が冗長であることを 16 進数が示唆する削除されたレコードを検出するための列が必要です。

彼のコメントは次のとおりです。

フィールドを使用deleted_xxして、レコードが削除されたことを判断しますか?

私見、最良かつ最も良い方法は、ブールデータ型のアクティビティ属性を記録するために追加することです（たとえば、という名前のフィールドACTIVE）。したがって、レコードを「削除」するには、単一の UPDATE クエリでACTIVEフィールド との値を更新する必要があります。すべてのアクティブなレコードを選択するには、次のようなクエリを作成する必要があります。update_dateupdated_by

SELECT * FROM MyTable WHERE ACTIVE=1

私は、Oracle Applications がそのようなアプローチを使用していることを知っており、同意します。

次の投稿も読みました。

• 削除された行をテーブルに格納する
• http://www.udidahan.com/2009/09/01/dont-delete-just-dont/
• http://ayende.com/Blog/archive/2009/08/30/avoid-soft-deletes.aspx

私の質問は:上記の 16 進数で提案されているように、 isActiveフラグを持つテーブルに一意の制約を設定する方法です。すべてのテーブルに代理キーがあります。ただし、自然キー列 (ビジネス キー列と呼ばれるもの) に一意の制約があることを確認したいと考えています。

deleted_on削除を追跡するフィールドがある場合は、この列を自然キー制約の一部として含めることができます。したがって、deleted_on 日付フィールドのみが異なる、同じビジネス キーの組み合わせを持つ複数の削除済みレコードが許可されます。

isActiveフィールドがありlast_updated_on、削除日を追跡するために列を使用する場合、自然キー制約に関する2つのオプションが必要です

1. isActive自然キー制約の一部として含めることができます。ただし、これにより、同じビジネス キーの組み合わせを持つ最大 1 つの削除済みレコードのみが許可されます。
2. 自然キー制約の一部としてisActiveプラスを含めることができます。last_updated_onしかし、deleted_on 列を追加すると簡単になります。

何かご意見は？ここで何か不足していますか？

現在、ezsqlライブラリを使用しています。ここで、phpを使用してmysqlデータベースと対話する別の方法を学びたいと思います。さまざまなトランザクションに使用されるデータベースに接続する場合、どの拡張子を使用する必要がありますか。pdo、mysqli、または推奨できるその他の拡張機能を使用する必要がありますか？

2 つのオフィス間でデータベース レプリケーション (トランザクション) をセットアップしたかったのですが、信頼できないチャネルを介して行うことをお勧めしますか? インターネット経由の VPN でこのトランザクション レプリケーションをセットアップする予定で、インターネット接続の中断を考慮しようとしています。他に考慮すべきトランザクション レプリケーションの問題はありますか?

また、更新可能なサブスクリプションを使用したトランザクション レプリケーションとマージ レプリケーションの違いを理解できませんでした。レプリケーションのベスト プラクティスについて推奨される記事や書籍はありますか。

SQL Server 2008 でこのレプリケーションをセットアップしたいと思っています。よろしくお願いします。

アイテムテーブルにレンタル用のアイテムがいくつかあります。アイテム テーブル内の各アイテムのレンタル履歴を示す多国籍テーブルがあります。アイテムが現在レンタルされていない場合、「利用可能状況」列のすべてのエントリは「クローズ」と表示されます。アイテムがレンタルされている場合、「利用可能状況」列のフィールドの 1 つに「ONRENT」と表示されます。各レンタル アイテムを一覧表示し、現在 "ONRENT" (利用不可) か "CLOSED" (利用可能) かを返すクエリを作成したいと考えています。WHERE 句で "ONRENT" を含む行のみを検索できるため、"ONRENT" であるレンタル商品を返すクエリを作成しました。「利用可能状況」列のすべての行が「クローズ」と表示されている場合、利用可能なアイテムを返す方法がわからない

この質問の提案に従って、関数を使用しto_regclassてテーブルが存在するかどうかを確認し、存在しない場合は作成しています。ただし、テーブルが現在のトランザクションで作成された場合to_regclassでも、 が返されるようnullです。

この動作は予期されたものですか? それともこれはバグですか？

詳細

これがうまくいかない場合の短い例を次に示します。