Re: Problems with SELECT *

>> According to Dennis Shasha's and Philippe Bonnet's recent update,
_Database
Tuning: Principles, Experiments, and Troubleshooting Techniques_, to Shasha's earlier book, a product called kdb physically stores tables as arrays of the columns. <<

And so does the Nucleus engine from Sand Technology, but with a different vector model than Kx uses. This approach assembles tables from columns on demand, so you only fetch what is needed for a query. The results are very, very fast for large amounts of data. You expect to get compression of the data because you can set up a domain for a column and use references to those values instead of repeating the value over and over.

Kx is used by the financial industry and Nucleus is used by TIA to process all that homeland security data.

These two products got over a hump that Tom Johnston pointed out years ago -- most SQL implmentations map the physical model directly to the logical model of SQL. A row is a physically contigous record, a column is physically contigous field with a record, and a table is a sequence of physically contigous records in a file in most products.

The bad news about the older products is that by exposing their particular physical model to the programmers, they will not be able to throw out the "code museum" when improvements like this come along. Received on Sat Mar 15 2003 - 02:05:24 CET