Re: Table(s) definition problem
Date: Fri, 27 Feb 2004 10:04:41 -0500
Message-ID: <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:04:41 CET