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

In article <Q%4y7.3030$4Y6.96616496_at_radon.golden.net>, Bob Badour says...
>
>"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.

If you can parallelize access so that 2 sets of users access 2 disjont sets of data, the total throughput increase is 2x. That is what I was refered to as "small" effect.

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

They are the same. However, "materialized views" sounds better to me.

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

Bitmap join indexes are already out there. And one can create any indexes on materialized views, of course.

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

Would it be faster than just indexing primary and foreign keys? If B-tree is 3 levels deep with the upper 2 levels being memory-resident, it's the same amount of disk navigation, because only traversal on the leaf level translates into disk access. With more than 3 levels, pointers seem to be faster.

On the other hand, what is the maintenance for pointer pools involved? Obviosly, it is not sufficient to have one way pointer only, as the row may move, so that the address have to be adjusted accordingly. Therefore a collection of pointers is needed to be attached to a record. Rather than going into this trouble, relational vendors have chosen to use indexes instead. This is my pure speculation, of course. Received on Tue Oct 16 2001 - 23:40:53 CEST