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

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. Besides, you seem to [unintentionally] encourage table design with numerous columns (see "The stupidest table I ever saw":-)

>> Alternatively, you can split the table into 2 one-to-one related
>> tables, and rename the old table into a view. As this would be "key
>> preserving view" (Oracle terminology) it would be updatable.
>
>Physical independence means that one should be able to alter the
>physical storage without altering the logical interface. While Oracle
>might allow updates to the view, unfortunately, not all SQL products
>will.

This is a world of competition: Oracle added bind variables literal substitutions because their competitor did so.

>> 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.

>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.

>> > 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. Received on Thu Oct 11 2001 - 04:04:35 CEST