0

次のシナリオに対処するためのアイデアはありますか?

私は、公開された階層データを格納する SQL システムを持っています。データがパブリッシュされると、元の階層を編集することはできず、パブリッシュされるときに新しいドラフト階層に変更を加える必要があります。

例として、階層を格納するためにそれ自体を参照する従業員のテーブルがあるとします。

  • 従業員
  • ID
  • Unique_Employee_Id (階層全体で変更を追跡できるようにするため)
  • 名前
  • 親ID

現在公開されている次の構造を使用します。

ボブ (ID: 1、ParentId: null)

  • ジョン (ID: 2、ParentId: 1)
  • サラ (ID: 3、ParentId: 1)

今、新しいノードを追加したいので、現在行っていることは、階層を複製することであり、すべての変更がこの新しい階層に次のように適用されます。

ボブ (ID: 5、ParentId: null)

  • ジョン (ID: 6、ParentId: 5)
  • サラ (ID: 7、ParentId: 5)
  • ケビン (ID: 8、ParentId: 5)

私の懸念は、階層が最大 2000 ノード以上になる可能性があることを知っていることです。実際には、これらの Employee ノードのそれぞれにぶら下がっているテーブルがさらに多くあり、これらもコピーする必要があり、更新を実行するときにパフォーマンスの問題が発生し始めます。階層に

リスト内の 1 つの項目のテキストを少し変更すると、階層全体とそれに関連するすべてが複製されます。

私は現在、リビジョン管理タイプの問題に取り組んでいると考えていますが、それを実装する方法がわかりません。

編集：

クローンが発生している理由を詳しく説明すると、ドラフトと以前に公開された階層の両方をいつでも表示できるため、既存の公開された階層に新しいノードを追加できず、新しいバージョンの階層に追加する必要があります。また、同じ理由で、公開された階層に属するノードを編集できません。

現在、機能するクローン方法を実装していますが、スケーラビリティに懸念があるため、変更を加えるために階層でディープ クローンを実行せずに上記の要件を満たす代替設計があるかどうかを知りたいと考えています。そのようなソリューションの。

For example source control systems do not store complete copies of a project for every change that is made but can recreate document hierarchy at any given change set and I am wondering if there is a similar pattern to this I could implement in SQL that would perform better then a deep clone.

4

1 に答える 1

0

編集したテストを読んだ後、「ドラフト」データを保存する新しいテーブルを作成することが解決策になると思います。

Employee_draft
session_id   #because you share this table with other user sessions
temp_Id      #will be replaced where you commit changes
Name
ParentId     #foreign key to Unique_Employee_Id
CUD          #kind of operations: Create (new/insert), Update, Delete

次に、一時テーブルに変更が加えられます。UI (ユーザー インターフェイス) は両方のテーブルを組み合わせて、ユーザーに変更を表示します。ユーザーが変更をコミットすると、競合が検出されない場合 (同時実行)、アプリはドラフト テーブルを実際のテーブルに「マージ」し、すべての session_id 行を削除します。

于 2012-08-16T16:29:07.630 に答える