Re: Table(s) definition problem

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 27 Feb 2004 10:39:37 -0500
Message-ID: <cYqdnYwYAqxs-aLdRVn-hQ_at_golden.net>


The logical model has no bearing on physical size. As a first-order approximation, a view requires no storage.

"Robert Stearns" <is_at_uga.edu> wrote in message news:c1nm6d$rme$1_at_cronkite.cc.uga.edu...
> 2 things: space-time, the several table method reduces the space
> required by 50% to 70%, thus the time needed to transfer result sets
> (also time is reduced since there fewer (usually many fewer) rows in the
> Gi tables than in G1); pesentation to the user, we have to expose some
> representation of the database to the user to allow ad hoc querying.
>
> Bob Badour wrote:
> > "Robert Stearns" <rstearns1241_at_charter.net> wrote in message
> > news:403E6F11.4070800_at_charter.net...
> >
> >>I have a very wide table (over 1000 attributes). I can group the
> >>attributes into several, ~20, disjoint sets where the elements of each
> >>set occur together. Call these sets of attributes G1, G2, ..., Gn. One
> >>set, say G1 defines the existence of the row, with a1, a member of G1 as
> >>its key.
> >>
> >>Is it better practice to have one large table with all the attributes in
> >>it, even though there will commonly be several missing Gi in each row,
> >>or should there be a table for each G with key a1? If the latter, what
> >>is the form, assuming SQL, of queries which behave as if you had one
> >>large table?
> >
> >
> > Assuming the availability of views, what's the difference?
> >
> >
>
Received on Fri Feb 27 2004 - 16:39:37 CET

Original text of this message