Re: Database design

Mark Johnson wrote:
> But there are important considerations
> addressed by database builders having to
> do with integrity (floating, loose records), and simply the rate at
> which queries can be performed. That was the reason for many looking
> to an explict/full/materialized path for such tables which otherwise
> violate the basics of the RM. The idea was that tables derived from
> the RM would not be ordered. But these hierarchical tables are
> explicitly ordered and by self-referential links. It's even worse than
> mere 'storage order'. And if one were to suggest - but wait, it's
> basically a bunch of normalized tables all overlayed on the same
> logical table for convenience, and because it lends itself easily to
> automated programmatic control - they'd probably be having none of
> that, particularly because one is not constrained to view any
> particular list, but could pick any tree, or the table as a whole,
> intentionally or by mistake.

I guess that if I spend some time on this, I may extract some sensible statements out of this. In the labour division between one writer and many readers it be better that the writer do the extraction work.

> Proponents of the RM against such schemes would certainly argue that
> they only have in mind the reduction of confusion, of error, and an
> increase in the speed and simplicity of retrieval of the data by
> whatever ordering. And if Connect By is burdensome or slow, even just
> in that they have a point, never mind that it is proprietary. Perhaps
> if it were as easy to transparently create tables without overhead or
> explicit design, as it is to add subtrees and leaves to a hierarchies,
> it might be less of an issue. But even in a well-known organization,
> with few anticipated changes in structure and order, surely some
> things come up, if just forced on them by changes made by large
> clients or vendors. I think that's why Oracle does have a Connect By,
> in the first place. And I'm sure many companies get a lot of use out
> of it.

Idem. Received on Sat Feb 25 2006 - 13:13:07 CET