管理者によって承認されるまで、ユーザーがプロファイルに対して行った編集を、ライブに移行したり、既存のライブデータに影響を与えたりしないように保存する方法を理解しようとしています。編集されたプロファイル用の2番目のテーブルがあり、承認時にデータをコピーしますか？すべてを1つのテーブルに保持し、編集可能なすべてのフィールドの_tmpコピーを持っていますか？このためのベストプラクティスはありますか？
あなたの考えをありがとう。
6 に答える
2
別のテーブルを持つことは私には良いことだと思います。そうすれば、変更されたものだけを保存でき、他のすべては保存できません。
于 2009-09-09T21:48:43.200 に答える
2
簡単にするために、データベースの「ステータス」列を使用して、特定の行が公開されているかどうかを判断することがよくあります。次に、SQLに次のように追加します。
WHERE status = 'published'
これは単純なサイトでうまく機能します。
忙しいサイトの場合、WHERE句がないことでパフォーマンスがいくらか向上すると思います。別のテーブルで保留中の編集を行うことは良いオプションです。次に、INSERT INTO ...SELECTFROMを使用してライブテーブルに移動します。
于 2009-09-09T21:52:26.630 に答える
1
アプリケーションにワークフローを少し組み込むことができます。そのため、さまざまな状態（入力、提案、承認など）を定義したワークフローテーブルが作成されます。
次に、これらの提案された変更を格納するPendingChangesテーブルを作成することもできます。提案された変更が承認されたら、その変更をメインのユーザープロファイルの変更にマージします。
于 2009-09-09T21:45:53.030 に答える
1
このようなケースが（多くの異なるテーブルにまたがって）多くある場合は、承認されるまでXMLまたはその他の状態への変更をシリアル化するTempObjectテーブルを作成できます。
または、それが単なるユーザープロファイルテーブルである場合は、UserID + Approved（boolean）に一意のキーを設定できます。ユーザーがデータを編集すると、データはUserID、Approved = falseとしてテーブルに追加され、承認するには、承認されたデータを削除し、承認されていないデータを承認済みに更新します（もちろんトランザクションで）。
結局のところ、あなたはすでにそのすべてのデータを保持するための構造を持っています-なぜそれを再利用しませんか？
于 2009-09-09T21:50:50.733 に答える
1
これは最も単純なようです。USERSテーブルにVERSIONフィールドとSTATUSフィールドを追加できます。次に、必要に応じて、STATUSフィールドを使用して最も高いVERSIONの行を表示します。明らかに、これによりレコードのバージョン管理も可能になります。
VERSIONとSTATUSにインデックスが付けられている限り、表示操作が実際に遅くなることはありません。インデックスを維持する必要があるため、行の追加は少し遅くなります。
于 2009-09-16T05:54:11.213 に答える
0
最初のテーブルと同じ形式の2番目のテーブルでは、複数の変更を簡単にキューに入れることができません。
各変更要求を変更要求として記録する特定の構造を設計することをお勧めします。誰が変更するのか、何が変更されるのか、何をするのか、誰がリクエストしたのか、いつなどのフィールド。
次に、検証された場合に変更を適用するためのコードを用意します。
これは、追跡しやすい監査証跡としても機能します。
同じテーブルで変更を加えることはしません。実装を緊密にバインドし、後のメンテナンスを頭痛の種にします。独立性は、将来の柔軟性を高めるために、すべてがどれほど緊密に結合されているかを減らします。
于 2009-09-09T22:11:30.050 に答える