Re: theoretical question on the RDBMS

Paul,

  The mix certainly can be confusing, but I assume flexibility at the physical level is extremely hard to provide if one of the goals is blinding speed - I'm sure the query optimizers in major products can't deal with much flexibility about where the data is.

  Good point about the sparse tables, though - I didn't make the connection, and in fact variable-length columns in SQL Server and probably most products are actually stored as variable-length, and it could even be a good space-saving trick to store an integer column as varchar() if it's often null and not indexed.

Steve

Paul wrote:

> Steve Kass <skass_at_drew.edu> wrote in message news:<3D5A4AA0.27A3623A_at_drew.edu>...
> > I don't see where files and devices say anything about independence,
> > and I suspect Paul is right that insofar as the theory talks about
> > independence, it almost has to mean something logical, not physical.
>
> I've just been reading a different but related thread ("normalization
> question") where you were wondering about data complexity and for
> example separating out a column which is usually NULL into a different
> table to save space. For some reason Google isn't letting me reply to
> that (too old?) but it's kind of relevant here.
>
> I think perhaps (guess who's been reading the dbdebunk website) this
> is something that should be done at the physical, not logical level.
> i.e. behind the scenes the database could implement "sparse" columns
> in a separate "file" for performance reasons but at the logical (SQL)
> level it should be in the same table.
>
> It seems to me perhaps there are two levels to being a DBA, one which
> is purely concerned with the logical level: SQL, data integrity, etc.
> where performance is irrelevant, and the other at the physical level,
> where decisions about indexing, table-to-file mappings etc. are made.
> I think perhaps current DBMSs are lacking in flexibility for the
> second (physical) level and tend to mix the two together in a way that
> can be confusing.
>
> Paul.
Received on Thu Aug 15 2002 - 14:49:09 CEST