0

Would anyone have ideas on dealing with the following scenario?

I have a SQL system that stores hierarchical data which is then Published. Once the data is published it is not possible to edit the original hierarchy and any changes have to be made to a new Draft hierarchy when in turn will be published and so on.

As an example lets say I have a table of employees which references itself to store a hierarchy.

  • Employee
  • Id
  • Unique_Employee_Id (so I can track changes across hierarchies)
  • Name
  • ParentId

With the following structure that is currently published:

Bob (Id: 1, ParentId: null)

  • John (Id: 2, ParentId: 1)
  • Sarah (Id: 3, ParentId: 1)

Now I want to add a new node so currently what I am doing is I clone the hierarchy and all changes are now applied to this new hierarchy like so:

Bob (Id: 5, ParentId: null)

  • John (Id: 6, ParentId: 5)
  • Sarah (Id: 7, ParentId: 5)
  • Kevin (Id: 8, ParentId: 5)

My concern is that I know the hierarchy can go up to 2000 nodes or more and in reality there are many more tables that hang off each of those Employee nodes which would also need to be copied and I will start running into performance issues when performing updates to a hierarchy

A small text change to one item in the list results in the entire hierarchy and everything related to it getting cloned.

I am thinking that I am currently into a revision control type problem but I am unsure how to go about implementing it.

Edit:

To expand on why the clone is happening, you can view both the draft and the prior published hierarchies at any point so I cannot add new nodes the existing published hierarchies I have to add them to a new version of the hierarchy. Also I cannot edit any nodes belonging to a published hierarchy for the same reason.

Currently I have implemented a clone method which works but I am interested in knowing if there is an alternative design I could use that would meet the requirements above without performing a deep clone on the hierarchy in order to make changes as I have concerns about the scalability of such a solution.

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

After read your edited test, I think that a solution may be to create a new table to store 'draft' data:

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

Then, changes are maded in temp table. UI (user interface) mix both tables to show user the changes. When user commit changes, app 'merge' draft table into real one if no conflicts are detected (concurrency), then delete all your session_id rows.

于 2012-08-16T16:29:07.630 回答