> Personally, I'm really only interested in something elegant. Meaning I
> don't want to mess around with a solution where this broker communicates
> with that broker via an n-way blah blah blah. I can maintain literacy
> in several tools at once, but not several dozen. Is my best bet simply
> to accept SQL's limitations and program around them in C++ (or C, or
> Python, or Perl, etc.)?
Good question! I have certainly given this one some thought before. One of my
projects involved a directory structure of sorts which allowed non-cyclic
symlinking. My solution in this case was to create a seperate table that was a
'map' -- the map was a pre-calculated, flattened version of the entire graph.
Thus, a single query of the map table for "/blah/blah2/etc/" returned
immediately correct subdirectory. Each time the linking tables are updated,
the map table must be re-calculated. This solution will not work for the
general cyclic graph, of course... and it may be inappropriate for the
situation where the link tables are update frequently since each update forces
a large recursive caluculation of the map -- the primary advantage is the speed
and easy of querying.
I am not aware of any SQL constructs of 'for' loops or 'while' loops, so I am
not sure how one could solve the problem in pure SQL -- actually, you probably
could using a recursive stored procedure.
Andy
