Re: Clean Object Class Design -- What is it?

"Mikito Harakiri" <nospam_at_newsranger.com> wrote in message news:T67x7.23970$ev2.32613_at_www.newsranger.com...
> In article <cd3b3cf.0110101531.3d71cdb5_at_posting.google.com>, Bob Badour
says...
> >
> >mikharakiri_at_yahoo.com (Mikito Harakiri) wrote in message
> >> What are advantages of breaking up table vertically?
> >
> >Different performance characteristics. If two or more disjoint groups
> >of users tend to access non-overlapping sets of attributes from a
> >relation, partitioning the data vertically will reduce concurrency
> >collisions, reduce the number of page reads required for any given
> >query, etc.
>
> This is small effect, IMHO, compared to horizontal partitioning, and
indexes, especially.

You discount the potential effect of concurrency contention, IMHO. You also make assumptions regarding performance based on no information whatsoever.

> Besides, you seem to [unintentionally] encourage table design with
> numerous columns (see "The stupidest table I ever saw":-)

I neither encourage nor discourage table designs with numerous columns. The number of columns should be inherent in the data managed.

> >> What is indexing on partial aggregates? If one wants to speed up a
> >> query like this:
> >>
> >> select deptno, sum(sal) from emp group by dept
> >>
> >> the standard technique is to create a materialized view and put an
> >> index on aggregate column.
> >
> >How many products allow materialized views?
>
> Same thing, tomorrow everybody will, because of the competition. This is a
> significant feature for data warehousing.

Data warehousing, itself, encourages bastardized logical data models for the sake of performance.

How, exactly, do materialized views differ from relational snapshots?

> >An index that maintains
> >partial aggregates at non-leaf nodes will add depth to the index but
> >will allow the DBMS to skip over increasing amounts of data as ranges
> >span nodes closer to the root. This applies to both linear indexes
> >such as B+Trees and multi-dimensional indexes.
>
> I'm not sure if your technique works for aggregates over joined tables.

That's another option that could improve physical independence that few or no products have implemented: multi-table indexes!

> >> > aware of any SQL product that uses physical pointers or pointer pools
among
> >> > tables to improve joins; although, surely there must be at least one.
> >>
> >> What are pointer pools?
> >
> >Pools (sets) of pointers.
>
> Well, if you want to keep it secret, fine with me. But it would be just
more
> appropriate to cut the paragraph as a whole.

What part of my explanation did you not understand? It seemed very clear to me, and I do not consider it a secret. Received on Sun Oct 14 2001 - 02:29:18 CEST