Sunday, February 19, 2012

About Replicating Graphs and Trees

I won't even get into the recursion and trees stuff since at 4:40AM just
might fry my brain.
The distributed issue really boils down to collisions. Collisions really
just boil down to data ownership. If you have a set which can be openly
modified by anyone at any time, you are going to have a complete mess no
matter what you try to do. The other side is that a data set is owned by
one and only one person which means others may be able to view it, but can
not modify it. This case means that you have no issues with synching since
you can't have collisions with data. For the case in between the two
extremes, you are back to the mess. Don't have a solution since even with
the conflict resolution available with merge, it doesn't solve your problem
but just shifts the burden to someone else.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
Still musing on all this -- the other way that I have been thinking about it
is -- to heck with the Graph part -- just work on keeping a list of
AdjacentLists in sycn, and after the synch is complete rebuild the Paths
table from it...from there on use the Paths.
But -- this would mean rebuilding the Paths on both the Server and on the
Client.
The client, I don't care -- that's his time, his cross to carry -- but on
the server, my findings have been that Celko's nested set theories were
clocking in at about 1000 records per second on a server. So a 10,000
record database would take 10 seconds about...
which would lock up the main path table for ten seconds for all users.
Make this 500 users -- we are talking about 5000 seconds -- so about 100
minutes a day. Yikes.
I have never checked to see to see if Celko's updates can be done with temp
tables and then dropping the main one and replacing it -- which would
decrease the amount of time offline -- but maybe make it impossible to allow
two users to synch at the same time...then again, all solutions probably do.
PS: I must admit, I do give Celko's techniques a hard time...and it's really
not his fault. More mine. But I have so much trouble understanding his stuff
because he wrote the book...well, for smarties...and I have to admit that
after reading it, I found out -- categorically -- that I am not one...no
matter how much I want to understand and use his stuff.
But...
If I were using MaterializedPaths, I would only have to rebuild/update the
fresh nodes...? Significantly less time.
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:erwAQqGIEHA.2016@.TK2MSFTNGP10.phx.gbl...
> I won't even get into the recursion and trees stuff since at 4:40AM just
> might fry my brain.
> The distributed issue really boils down to collisions. Collisions really
> just boil down to data ownership. If you have a set which can be openly
> modified by anyone at any time, you are going to have a complete mess no
> matter what you try to do. The other side is that a data set is owned by
> one and only one person which means others may be able to view it, but can
> not modify it. This case means that you have no issues with synching
since
> you can't have collisions with data. For the case in between the two
> extremes, you are back to the mess. Don't have a solution since even with
> the conflict resolution available with merge, it doesn't solve your
problem
> but just shifts the burden to someone else.
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>

No comments:

Post a Comment