Re: Problems with SELECT *

Originally posted by --Celko--
> >> 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.
>
> What is exactly the difference between Nucleus and
> Kdb? They both seem to store columns contiguously and use
> "enumeration"...
>
> Do you know of any comparison data between Nucleus and Kdb?
> .
>
> 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.

--
Posted via http://dbforums.com