Re: Hierachical structures - an overview

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:bta3ac$69i$1_at_news.netins.net...
> >
> and if I thought that there really were gains by taking an application that
> could be 10 non-RDBMS database"files" (tables that include tables as
> elements) and exploding it to more than 100 tables, I would be in favor of
> all those tables, but I don't, so I'm not. ;-)

I think it's a mistake to use such simplified metrics as counting the number of tables or counting the number of trees. Neither metric gets at the fundamental complexity of the schema. Whatever the degree of complexity of the schema is, that's what it is, and efforts to paper over fundamental complexity do more harm than good.

By analogy, I have noticed that junior Java programmers are sometimes reluctant to add classes, even when they have a perfectly valid abstraction. They will try to wedge the abstraction into an existing class. When I ask them why, they say they are trying to minimize the number of classes, because a lot of classes makes the system complicated. Their mistake is that in Java, classes are the fundamental unit of organization. Likewise, in an RDBMS, tables are the fundamental unit of organization. Consider: if reducing table count was a useful metric, we'd want to denormalize everything as much as possible. Ugh!

If you want to be sure your schema (or structure) is no more complex than it needs to be, then the best way to address that is with a formal set of normalization rules. If your table definitions are fully normalized, then you have the right number of tables, whatever than number may be.

Is there a formalized set of tree schema normalization rules?

Marshall Received on Mon Jan 05 2004 - 18:09:08 CET