Re: one record or many?
Date: Fri, 19 Jul 2002 12:08:38 +0200
Message-ID: <4eofjuo36l37dc5gtn76u5hjmvlcsgke1f_at_4ax.com>
On Thu, 18 Jul 2002 16:34:59 GMT, JXSternChangeX2R_at_gte.net (JRStern) wrote:
>On Thu, 18 Jul 2002 16:31:40 GMT, "Jeffrey Baler"
><jbaler_at_hcri.harvard.edu> wrote:
>>If a paper form is used to capture data in a "table format", with a fixed
>>number of rows, how should this translate to a relational table?...should it
>>be multiple records with the column attributes named as the paper form has
>>named its column headings? Or should it be translated into one record with
>>each attribute capturing one field of data from the paper form?
>
>The general form that is more likely to be 3NF (or even 1NF) is to
>have each row as a record. Do it now, it will save you rework later.
>
In particual this is called (as far as I remember) relations of known
cardinality. These are quite rare because sooner or later it becames
apparent that some artifical rule imposes them. Usually at the moment
the rule changes.
So go for two entities in the conceptual design.
I doubt that there is ANY justificaiton to do it as one entity in
conceptual design!
In the physical implementation of the conceptual design an expense of
this single join might be too big performance hit for your
application's specifications (?), and you might have to resort to
denormalization of some sort... (after you exhausted your DBMS
optimization options).
Keep in mind that every denormalization brings benefits only to
certain types of tasks and very big performance hits to other types of
tasks.
( GoranG79 AT hotmail.com ) Received on Fri Jul 19 2002 - 12:08:38 CEST