Continuing after my last response to your comment, and my laying out a basic
scenario, I went ahead with a larger set...which I present the work for
below.
As you can see...it looks tantalizingly close. Yet so far.
PS: Man! Do I hope you have the same font on your reader than mine...or the
following columns will be so out of whack...let me know if it comes across
ok.
*** STEP 1: Initial Setup
Server.Edges [Machine, GUID, LastEdited, VertexGUID, Path] looks like:
s s01 2004-04-01 .1
s s02 2004-04-01 .1.1
s s03 2004-04-01 .1.1.1
s s04 2004-04-01 .1.1.1.1
s s05 2004-04-01 .1.1.2
s s06 2004-04-01 .1.1.3
s s07 2004-04-01 .1.2
s s08 2004-04-01 .1.2.1
s s09 2004-04-01 .1.2.2
s s10 2004-04-01 .1.2.2.1
s s11 2004-04-01 .1.2.2.2
s s12 2004-04-01 .1.2.2.3
s s13 2004-04-01 .1.3
s s14 2004-04-01 .1.3.1
s s15 2004-04-01 .1.3.2
s s16 2004-04-01 .1.3.2.1
this is copied to the Pocket CE:
CE.Edges [Machine, GUID, LastEdited, VertexGUID, Path]
s s01 2004-04-01 .1
s s02 2004-04-01 .1.1
s s03 2004-04-01 .1.1.1
s s04 2004-04-01 .1.1.1.1
s s05 2004-04-01 .1.1.2
s s06 2004-04-01 .1.1.3
s s07 2004-04-01 .1.2
s s08 2004-04-01 .1.2.1
s s09 2004-04-01 .1.2.2
s s10 2004-04-01 .1.2.2.1
s s11 2004-04-01 .1.2.2.2
s s12 2004-04-01 .1.2.2.3
s s13 2004-04-01 .1.3
s s14 2004-04-01 .1.3.1
s s15 2004-04-01 .1.3.2
s s16 2004-04-01 .1.3.2.1
*** STEP 2: Both mess aroudn with tree, unsynchronized
Now both users and clients add to .1.1 (!!!) as well as others:
s s01 2004-04-01 .1
s s02 2004-04-01 .1.1
s s03 2004-04-01 .1.1.1
s s04 2004-04-01 .1.1.1.1
s s17 2004-04-02 .1.1.1.2 <- new
s s18 2004-04-02 .1.1.1.3.1 <- new
s s19 2004-04-02 .1.1.1.3 <- new
s s05 2004-04-01 .1.1.2
s s06 2004-04-01 .1.1.3
s s20 2004-04-02 .1.1.4 <- new
s s07 2004-04-01 .1.2
s s08 2004-04-01 .1.2.1
s s09 2004-04-01 .1.2.2
s s10 2004-04-01 .1.2.2.1
s s11 2004-04-01 .1.2.2.2
s s12 2004-04-01 .1.2.2.3
s s13 2004-04-01 .1.3
s s14 2004-04-01 .1.3.1
s s15 2004-04-01 .1.3.2
s s16 2004-04-01 .1.3.2.1
s s21 2004-04-02 .1.3.3 <- new
And on CE:
s s01 2004-04-01 .1
s s02 2004-04-01 .1.1
s s03 2004-04-01 .1.1.1
s s04 2004-04-01 .1.1.1.1
c c19 2004-04-02 .1.1.1.2 <- new
c c20 2004-04-02 .1.1.1.2.1 <- new
c c21 2004-04-02 .1.1.1.2.2 <- new
c c22 2004-04-02 .1.1.1.3 <- new
c c23 2004-04-02 .1.1.1.3.1 <- new
s s05 2004-04-01 .1.1.2
s s06 2004-04-01 .1.1.3
c c18 2004-04-03 .1.1.4 <- new
s s07 2004-04-01 .1.2
s s08 2004-04-01 .1.2.1
s s09 2004-04-01 .1.2.2
s s10 2004-04-01 .1.2.2.1
s s11 2004-04-01 .1.2.2.2
s s12 2004-04-01 .1.2.2.3
s s13 2004-04-01 .1.3
s s14 2004-04-01 .1.3.1
s s15 2004-04-01 .1.3.2
s s16 2004-04-01 .1.3.2.1
c c17 2004-04-02 .1.3.3 <- new
*** STEP 3a: Synchronization: Get new Records from Server
If you then "SELECT * FROM EDGES WHERE LastEdited > @.LastSycn" and merge
this in:
s s01 2004-04-01 .1
s s02 2004-04-01 .1.1
s s03 2004-04-01 .1.1.1
s s04 2004-04-01 .1.1.1.1
s s17 2004-04-02 .1.1.1.2 <- new *** CONFLICT BASE ***
s s18 2004-04-02 .1.1.1.3.1 <- new *** CONFLICT ***
s s19 2004-04-02 .1.1.1.3 <- new *** CONFLICT BASE ***
c c19 2004-04-02 .1.1.1.2 <- new *** CONFLICT BASE ***
c c20 2004-04-02 .1.1.1.2.1 <- new
c c21 2004-04-02 .1.1.1.2.2 <- new
c c22 2004-04-02 .1.1.1.3 <- new *** CONFLICT BASE ***
c c23 2004-04-02 .1.1.1.3.1 <- new
s s05 2004-04-01 .1.1.2
s s06 2004-04-01 .1.1.3
s s20 2004-04-02 .1.1.4 <- new *** CONFLICT BASE ***
c c18 2004-04-03 .1.1.4 <- new *** CONFLICT BASE ***
s s07 2004-04-01 .1.2
s s08 2004-04-01 .1.2.1
s s09 2004-04-01 .1.2.2
s s10 2004-04-01 .1.2.2.1
s s11 2004-04-01 .1.2.2.2
s s12 2004-04-01 .1.2.2.3
s s13 2004-04-01 .1.3
s s14 2004-04-01 .1.3.1
s s15 2004-04-01 .1.3.2
s s16 2004-04-01 .1.3.2.1
s s21 2004-04-02 .1.3.3 <- new *** CONFLICT BASE ***
c c17 2004-04-02 .1.3.3 <- new *** CONFLICT BASE ***
*** STEP 3b: Resolve Conflicts on Client
You would get several conflict groups ...But maybe that is resolvable via
code?
For example:
SELECT * FROM Client.Edges as E1, Client.Edges as E2 where E1.GUID !=
E2.GUID and E1.Path=E2.Path
I think(!) will give:
s s17 2004-04-02 .1.1.1.2 <- new *** CONFLICT BASE ***
s s18 2004-04-02 .1.1.1.3.1 <- new *** CONFLICT ***
s s19 2004-04-02 .1.1.1.3 <- new *** CONFLICT BASE ***
c c19 2004-04-02 .1.1.1.2 <- new *** CONFLICT BASE ***
c c22 2004-04-02 .1.1.1.3 <- new *** CONFLICT BASE ***
s s20 2004-04-02 .1.1.4 <- new *** CONFLICT BASE ***
c c18 2004-04-03 .1.1.4 <- new *** CONFLICT BASE ***
s s21 2004-04-02 .1.3.3 <- new *** CONFLICT BASE ***
c c17 2004-04-02 .1.3.3 <- new *** CONFLICT BASE ***
What I see here in this mess are several "bases", or conflict groups...the
question is how to
find them...hum...ok.
If I am seeing this correctly, it's where COUNT(GUID) > 1
Which would give the following:
..1.1.1.2
..1.1.1.3
..1.1.4
..1.3.3
This could be interesting -- if we could distinguish which one came from the
server (hence why i just added the Machine column) we could say that always
has priority (for the moment) and
make the c's new path equal to the next position available:
Gut Feeling: to resolve this, we have to make sure that the above list of
base conflicts is in Ascii order -- in other words tackle the problem
from the top of the graph -- not just in any order. Or is this just because
humans think this way in general, and math won't care, and it will work
out?
To do this we have to find the max child node of the parent (needs work for
exceptions):
(here, after typing something like this it makes me grin wryly at how I
wrote that...as if it were the only thing that needed massive overhaul!!!
;-)
Big Question: ChildNode Count of Parent -- but which one?! are we talking
about ChildCount of Server Node, or ChildNode, or Both?
What I am seeing from below is (Count(ServerAndClient.ChildNodes)-1)... no
idea where that is coming from.
Or Count(ServerOnly.ChildNodes)+1:
s s01 2004-04-01 .1
s s02 2004-04-01 .1.1
s s03 2004-04-01 .1.1.1
s s04 2004-04-01 .1.1.1.1
s s17 2004-04-02 .1.1.1.2 1.1.1.2 <- no change for server node.
s s18 2004-04-02 .1.1.1.3.1 1.1.1.3.1 <- no change for server node.
s s19 2004-04-02 .1.1.1.3 1.1.1.3 <- no change for server node.
c c19 2004-04-02 .1.1.1.2 1.1.1.4 <- change the CE
c c20 2004-04-02 .1.1.1.2.1 1.1.1.4.1 <- change the CE
c c21 2004-04-02 .1.1.1.2.2 1.1.1.4.2 <- change the CE
c c22 2004-04-02 .1.1.1.3 1.1.1.5 <- change the CE
c c23 2004-04-02 .1.1.1.3.1 1.1.1.5.1 <- change the CE
s s05 2004-04-01 .1.1.2
s s06 2004-04-01 .1.1.3
s s20 2004-04-02 .1.1.4 <- new *** CONFLICT BASE ***
c c18 2004-04-03 .1.1.4 1.1.5 <- change the CE
s s07 2004-04-01 .1.2
s s08 2004-04-01 .1.2.1
s s09 2004-04-01 .1.2.2
s s10 2004-04-01 .1.2.2.1
s s11 2004-04-01 .1.2.2.2
s s12 2004-04-01 .1.2.2.3
s s13 2004-04-01 .1.3
s s14 2004-04-01 .1.3.1
s s15 2004-04-01 .1.3.2
s s16 2004-04-01 .1.3.2.1
s s21 2004-04-02 .1.3.3 1.3.3 <- new *** CONFLICT BASE ***
c c17 2004-04-02 .1.3.3 1.3.4 <- new change the CE
Ok. I'm lost. I fritzed, can't hold it all together in my head, and I'm
pretty sure that I missed a step, and I'm just seeing meaningless numbers at
this point.
Is anybody else around here a person who handles math all day and the above
doesn't look like complete jibberish and can see patterns where I see
headaches?
Thanks!
I'm debating this. Need to go get another glass of Scotch. Things seem to
make more sense after a couple of them.
It wasn't making much sense until I changed my font to wingdings. Didn't
make any more sense after doing that, but it was much more entertaining!
I don't have any real answers on your manipulation of the trees. The
comparison to a file system isn't accurate. Simply because you aren't
allowed to take the file system offline like you can data, manipulate it,
and upload it back. You simply aren't allowed to do that specifically
because of the issue you are dealing with here. It causes instability of
the structure as well as introducing many cases which are unsolvable.
Allowing offline, full manipulation of the tree is going to land you in a
completely unsolvable situation. No mater what method you use to render the
tree, you still have to come up with a solution several issues:
1. Someone adding a child node to a parent which someone else has moved
which very may well render the business decision to add that child node
irrelevant.
2. Two different people adding the same node to the tree. I'm not referring
to the hidden, technical ID thing which end users have no clue what it is.
I'm talking about adding the same data value to the tree. This is mostly
resolvable, but you are going to require the use of very sophisticated data
mining algorithms to determine that the information that two different
people phrased completely differently is in fact the same data. You then
need to merge that data together as well as notifying the people generating
the data that it was merged so that they can verify that is in fact what
should occur.
3. Two people adding different nodes at the same initersection point in the
tree. Is it allowed? Does one addition cause the other to become obsolete.
4. One person deleting a node while another one moves it to a different
location. Which change stays or to both stay?
5. One person deleting a node with children while someone else updates one
of the children, adds children, or rearranges that portion of the tree? Did
the actions taken by the second person make the decision by the first
invalid? What do you do with the children and all of the changes if in fact
you decide that the delete should happen?
These are just 5 scenarios. You'll note that none of these scenarios are
based in any technological implementation. Every single scenario exists
regardless of how you render the tree. Every situation happens as soon as
you allow disconnected editing of the tree.
In mathematics, there are problems which fall into the classification of
"unsolvable". Is there a solution to them? No one knows. There are many
mathematicians still working on them, some of which were posed over 2000
years ago and while partial solutions exist, no complete solution has ever
been achieved. Your problem falls into the same category. Is there a
solution to it? No one knows, simply because the problem still has not been
solved. That isn't to say that there isn't a person capable of solving it,
it is to say that it is an INCREDIBLY difficult problem that thus far has
zero solution. You may be the first one to solve the problem, but before
you even get into the mathematics of the tree rendering, you have to get
into the mathematics of how to handle the disconnected editing issue.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||You wouldn't have some of that scotch to share?
Ok. So I gather that Synching trees is not a walk in the park. And that
Newton, Einstein, Pinky and the Brain, all failed at solving it...
Considering that I'm more on the level of Pinky, not the Brain, I've got
about a snowballs chance in hell in solving it.
But ...there's 'impossible' ...and 'good enough to hold through the day'...
At this point, I guess what I'm going to have to settle for is "Things we
can do", and "things that we can't do".
Btw: I'm continuing not because I just dont get a hint when I've been given
a strong one... and certainly not that I think I am smart enough to figure
this out.
It's just that...I really really needed to use it... or my XXX is grass at
this current job. So... I'm going to continue sketching lines and arcs until
I go blind.
What can we do with the various techniques at our disposal:
Using AdjacentList theories rather than Celko's or MaterializedLists, one
can deal with the following problems you brought up.
> 1. Someone adding a child node to a parent which someone else has moved
> which very may well render the business decision to add that child node
> irrelevant.
True -- but duplication such as this can be 'cleaned' up by the user who
added it after he realizes that it is redundant, when he gets back to the
office?
Not great -- but "possible".
> 2. Two different people adding the same node to the tree. I'm not
referring
> to the hidden, technical ID thing which end users have no clue what it is.
> I'm talking about adding the same data value to the tree. This is mostly
> resolvable, but you are going to require the use of very sophisticated
data
> mining algorithms to determine that the information that two different
This is not my problem. Atleast today. As far as I can see, in the real
world, people duplicate a ton of things anyway...then realize that was done
by someone else, and throw the paper away (re-delete the node).
And the fact that we are talking about tasks, if we end up with two people
putting in the same task, it's pretty obvious to the receiver that they are
the same thing, and igore or delete one...?
Again, Not great -- but "possible".
> 3. Two people adding different nodes at the same initersection point in
the
> tree. Is it allowed? Does one addition cause the other to become
obsolete.
Intersection point? I don't know that term. Are we talking about the same
Materialized Path?
If so, then yes - it's up to the synch device to renumber them/reorder them.
As you pointed out, the end user doesn't care what their numbering/guid/path
is -- just as long as it Looks like it is in the right location.
This is especially moot in the case of Adjacent Lists since there is no
Order...?
Again. Holding, albeit rough.
> 4. One person deleting a node while another one moves it to a different
> location. Which change stays or to both stay?
Now, HERE we have a problem. Beats me.
Guess I would have to do it based on time... but if the delete is timed as
being later than the move then one ends up with disconnect islands of
nodes... Hum.
> 5. One person deleting a node with children while someone else updates one
> of the children, adds children, or rearranges that portion of the tree?
Did
> the actions taken by the second person make the decision by the first
> invalid? What do you do with the children and all of the changes if in
fact
> you decide that the delete should happen?
I think by breaking the Edges into a secondary table and not keeping it so
closely linked to the Vertex, then the deleting a Record is not a direct
result of deleting a link, but rather a case of deleting the Record only
when the Valence of the Vertex becomes 0...sort of how MS handles COM
activex objects...
Or, more importantly, that these delete decisions are never handled on the
Client. Only on the server. It might have no more Edges to it on the Client,
hence is invisible /inaccessible, but the Vertex and its data is still there
until
the server does a cleanup routine and sees that there are Vertexes with
Valence=0, deletes them, and the Records that they are pointing to...
Who knows.
I'll keep messing around. Not everything can be solved -- I can see that --
but if I can get the number of "impossibles" down to "ok. So it will glitch
some times", but the overall usefullness is worth it", then I can work with
it until a better theory/plan of attach becomes available...
PS:
By the way Michael -- thanks for all the great help. I might not be getting
a "how to do it" response -- but I very much appreciate the fact that you
have put in so much considered time into your responses.
Thanks.
(Even if you are just treating my messages as an excuse to hit the bottle
again ;-)
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:OHvHQ%23dIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> I'm debating this. Need to go get another glass of Scotch. Things seem
to
> make more sense after a couple of them.
> It wasn't making much sense until I changed my font to wingdings. Didn't
> make any more sense after doing that, but it was much more entertaining!
> I don't have any real answers on your manipulation of the trees. The
> comparison to a file system isn't accurate. Simply because you aren't
> allowed to take the file system offline like you can data, manipulate it,
> and upload it back. You simply aren't allowed to do that specifically
> because of the issue you are dealing with here. It causes instability of
> the structure as well as introducing many cases which are unsolvable.
> Allowing offline, full manipulation of the tree is going to land you in a
> completely unsolvable situation. No mater what method you use to render
the
> tree, you still have to come up with a solution several issues:
> 1. Someone adding a child node to a parent which someone else has moved
> which very may well render the business decision to add that child node
> irrelevant.
> 2. Two different people adding the same node to the tree. I'm not
referring
> to the hidden, technical ID thing which end users have no clue what it is.
> I'm talking about adding the same data value to the tree. This is mostly
> resolvable, but you are going to require the use of very sophisticated
data
> mining algorithms to determine that the information that two different
> people phrased completely differently is in fact the same data. You then
> need to merge that data together as well as notifying the people
generating
> the data that it was merged so that they can verify that is in fact what
> should occur.
> 3. Two people adding different nodes at the same initersection point in
the
> tree. Is it allowed? Does one addition cause the other to become
obsolete.
> 4. One person deleting a node while another one moves it to a different
> location. Which change stays or to both stay?
> 5. One person deleting a node with children while someone else updates one
> of the children, adds children, or rearranges that portion of the tree?
Did
> the actions taken by the second person make the decision by the first
> invalid? What do you do with the children and all of the changes if in
fact
> you decide that the delete should happen?
> These are just 5 scenarios. You'll note that none of these scenarios are
> based in any technological implementation. Every single scenario exists
> regardless of how you render the tree. Every situation happens as soon as
> you allow disconnected editing of the tree.
> In mathematics, there are problems which fall into the classification of
> "unsolvable". Is there a solution to them? No one knows. There are many
> mathematicians still working on them, some of which were posed over 2000
> years ago and while partial solutions exist, no complete solution has ever
> been achieved. Your problem falls into the same category. Is there a
> solution to it? No one knows, simply because the problem still has not
been
> solved. That isn't to say that there isn't a person capable of solving
it,
> it is to say that it is an INCREDIBLY difficult problem that thus far has
> zero solution. You may be the first one to solve the problem, but before
> you even get into the mathematics of the tree rendering, you have to get
> into the mathematics of how to handle the disconnected editing issue.
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>
|||It's not giving a strong recommendation, as I sip on a glass of Macallan 25
at 4:30AM
. It's saying there very well may not be an answer. I'd sayit's a little harsh to say that you are toast at your current job if you
can't completely solve a problem that no one else has ever been able to
solve. My answer to someone who wanted to fire me for something like that
would be "You solve it or give me a single example in any industry where
this type of problem exists that has a solution". I'd probably then find a
different job on my own. While I enjoy accomplishing what others seem to
think is impossible, being required to solve the impossible as a condition
of continued employment is going a bit too far. Would you fire a doctor who
doesn't have a cure for cancer and can't find one within the next 30 days?
You learn a lot of things during your education. There are exactly 2 things
which have stuck with me to this day. (I majored in physics and thought
playing with high energy physics where "we invented the math to solve the
problems" was pretty fun.)
1. A very wise high school math teacher who taught Calculus to me and a
bunch of teenagers who thought they already knew it all once told me: "The
best mathematician is a lazy mathematician. Not lazy enough that he doesn't
do his work, but lazy enough to find the easiest way".
2. A caption on a poster of Einstein hanging in my physics advisor's
office. "The uneducated accomplish the impossible every day, because they
don't know any better."
Based on #2, I'd give Pinky a much better chance that the Brain to rule the
world, but he'd have to figure out a way to get it away from Wakko, Yakko,
and Dot first since they already know how to rule the world.
The problem you are trying to solve isn't trivial. Coming up with a
solution that will work under all permutations may not even be possible.
Therefore, you may need to "legislate" a solution, i.e. place business rules
around restrictions you impose. You may also have to set up very regimented
documentation that lays out exactly how the system will react under
different scenarios.
Now, my first suggestion based on the fact that you are buried VERY deep
inside this problem and have been hammering it for quite a while is to take
everything you have been drawing, scribbling, etc. and stick it in a desk
drawer. Leave the office and go walk around a park for an hour or so,
completely ignoring the problem you are working on. Go back to your office,
take our a clean sheet of paper, take a BIG step back, and define the
problem from a BUSINESS perspective.
You are neck deep in technical gobbledygook. How do I know? I posed a
bunch of business scenarios. Your response was technical solutions to each
one. How do you know they are right?
One thing that a lot of high energy physics taught me along with many years
of designing systems and playing in this industry I call a hobby is that you
have to completely define the problem first. You are going after pieces and
parts and trying to stuff everything into a technical option.
Your basic problem is that you have a tree with many nodes and potentially
many levels. You have to allow users to freely manipulate that tree, some
of the manipulations may conflict with each other. You have to figure out
how to resolve all of the conflicting manipulations. You can NOT do that
unless you first define what each one is. Once you define what each one is,
you have to come up with a BUSINESS decision on how to handle each and every
exception that could be caused. Only after you have defined the problem
which includes how the BUSINESS wants each exception handled, do you begin
on devising a technical solution to the problem.
You take each possible technical solution and run it up against the BUSINESS
problem you have and note any exceptions which could occur that do not allow
the technical solution to solve the BUSINESS problem. You will either
eventually devise a solution or you will exhaust all possibilities. If you
exhaust all possibilities, you then have to take the problem back to the
BUSINESS and explain precisely how their business requirements can not be
met with any available technical solution. You are going to have to be
prepared to explain in very gory detail what you did, how you did it, and
precisely where each technical solution fails to meet requirements and why
it fails. At the point, the BUSINESS is going to have to make a BUSINESS
decision to either limit the scope or place additional restrictions which
may make it possible to implement.
Not every problem has a solution in the general case. But, any problem
subjected to enough restrictions and enough parameter control will
eventually yield a solution. It is up to you to decide whether those
restrictions placed in order to achieve a solution still allow you to meet
an acceptable level of the business requirements.
Some of your answers above are not that straight forward. As soon as you
say "not my issue", you are going to get hung out to dry, because you are
going to be the one that gets blamed by the users when your system does
something they don't like.
1. Can the user really clean up the data? You are assuming only 2 people
involved here, that each person can recognize their own changes separate
from everyone elses and that there is immediate follow up. What happens
when 5 people add the same node while another 20 people are rearranging that
part of the tree, they all synch up and go on a 1 week vacation. They come
back realize something really screwy is going on and call you to find out
why your system has their data all screwed up. Each of the 5 people then
decide, between synchs, to delete the other 4 duplicate nodes without
consulting anyone else resulting in an aggregate of all 5 of the nodes being
deleted which prompts another call to you to explain why data is
disappearing from your system.
2. It isn't? Are you really, really, really sure about that? See point #1.
3. No. I used intersection point very explicitly instead of using techno
babble. A tree grows branches. It's a useful comparison to what you are
doing. Each offshoot, child node", intersects with a larger branch, "parent
node", at a certain point. What would happen if the tree all of a sudden
decided that it would be really neat to start two new branches at precisely
the same intersection point on a limb? (It does happen in nature, but your
problem is much more complicated.)
4. Not really. Part of that is in note #1 above. Your solution also breaks
down in the face of a business, which is what the problem is supposed to be
for anyway. Let's put this one more specifically. At 8AM, both Joe the new
salesperson and Sally the CEO synch up their data. At about 8:30 AM, Joe
decides to delete a node. At about 9AM, Sally decides to move the same node
that Joe had deleted. They both synch up at 11AM. What do you do? I've
explicitly left these types of things out of the previous post, leaving them
to you, but realized that you were too far into the technical solutions to
not look at all of the permutations. We've introduced another variable into
the equation here which says that not all inserts/updates/deletes are equal.
There are different levels of authority which must be considered when there
is any conflicting reorganization of the tree.
5. Edges, vertexes, valences, blah, blah, blah. You missed the point of
that scenario. Not only is it a very real collision scenario, but it also
has the same implications described in #4.
Again, back away from the technical side and work on defining the business
side first. You can't see the top of a Redwood when you are standing 1"
away from the trunk. You have to back up about 100 feet to really
contemplate the enormity of of what you are looking at.
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