Re: About Replicating Graphs and Trees
From: Sky (forums_at_xact-solutions.removethis.com)
Date: 04/12/04
- Next message: NO.bruceradtke.SPAM_at_NO.earthlink.net.SPAM: "Conflict table cleanup"
- Previous message: Indra: "How to filter the row in merge replication."
- In reply to: Michael Hotek: "Re: About Replicating Graphs and Trees"
- Next in thread: Michael Hotek: "Re: Q: About Replicating Graphs and Trees"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 12 Apr 2004 20:12:23 +0200
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
>
>
- Next message: NO.bruceradtke.SPAM_at_NO.earthlink.net.SPAM: "Conflict table cleanup"
- Previous message: Indra: "How to filter the row in merge replication."
- In reply to: Michael Hotek: "Re: About Replicating Graphs and Trees"
- Next in thread: Michael Hotek: "Re: Q: About Replicating Graphs and Trees"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
