Re: Hierarchical queries and indexes

From: robert <gnuoytr_at_rcn.com>
Date: 8 Oct 2004 08:50:46 -0700
Message-ID: <da3c2186.0410080750.2fa60908_at_posting.google.com>


Troels Arvin <troels_at_arvin.dk> wrote in message news:<pan.2004.10.05.11.46.48.266310_at_arvin.dk>... <snip>
> I realize that hypothetical thoughts on how things could/should be done in
> RDBMSes sometimes conflict with potential implementation difficulties,
> backwards compatiblity issues, etc. - But since this is a theory-group, I
> hope someone is interested in discussing why hierarchical encoding models
> have to exist.

a couple of reasons:

primary: with unix and the ms-dos (pc-dos), the notion of tree structured

          file systems arose.  this had not been true previously.  since
          humans do 99.44% of what they do by extension, the notion that
          the "standard" structure of data as hierarchy took hold.

secondary:  there are some naturally occurring hierarchies --> org charts
            and bills of material, mostly.  

the problem with pushing lots of square pegs (structures which are not inherently hierarchical) into round holes (hierarchies) leads to all sorts of kludges. XQuery is just the latest.

since Dr. Codd had IMS (a hard-wired hierarchical DB) as current practice, it is odd that the RDBMSs (and SQL) still don't handle them natively. i'll ignore SQL-99 common table expressions, since they only exist in the unix/windoze version of DB2.

one other issue with this sort of "model" is: how to handle intrusion of meta-data.

for example, assume three generic tables (Mr. Celko, control your blood pressure); table1, table2, table3. now, the designers (loosely defined) decided that some data in table1 would be joined to some data in either table2 or table3. in order to record this relationship, there is a column in table1, next_table. the data is either 'table2' or 'table3'. there is a second column in table1, next_table_key_value, which is an actual data value in table2 or table3; possibly both. processing these tables with SQL is not, in my estimation, possible.

the designers have defined my such hierarchies, to varying depths, among 100s of tables in this way.

so, it can be worse. and yes, so far as i'm concerned, doing the above reveals one to be as dumb as a sack of hair (to quote a texas friend); but antique COBOL programmers, and juvenile java programmers seem to think it's peachy keen. at least those from those groups that i work with. they don't have to do anything but serial select(s). and write a tonne of code to keep it all from falling apart; but, hey, that's their job.

BobTheDataBasyBoy Received on Fri Oct 08 2004 - 17:50:46 CEST

Original text of this message