Re: one record or many?

From: GoranG <no_at_spam.net>
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

Original text of this message