Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!amcad!stech!sysop
From: sysop@stech.UUCP (Jan Harrington)
Newsgroups: comp.databases
Subject: Re: Database problem of the week
Message-ID: <126@stech.UUCP>
Date: Thu, 13-Aug-87 07:26:16 EDT
Article-I.D.: stech.126
Posted: Thu Aug 13 07:26:16 1987
Date-Received: Sat, 15-Aug-87 10:52:23 EDT
References: <923@woton.UUCP>
Organization: Scholastech, Inc., Waltham, Mass.
Lines: 35

in article <923@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) says:
> Quandary: "Bob"
> 
> Currently the data is stored in a single large Informix file in which each
> record consists of a key and 52 floating point lab values.  The key is a
> composite of a study group number, a subject number and a time. 
> 

What you describe is a classic relational database design problem.  Whoever
designed the database thought of it as if he or she were using a flat file
manager, not a database management system.  Your PLAN A looks like the best
solution.  You might want to do the following:

	table 1: Subjects (subject number, name, phone, age, sex, etc. -
		any data that don't change from one experimental session
		to another)

	table 2: Groups (group number, description, etc. - any data that don't
		change from one experimental session to another)

	table 3: Experimental data (subject number, group number, date, time,
		value id, value)

If subjects remain with the same group throughout their participation in
the experiment, then the group number can be part of table 1 and isn't needed
in table 3.

Because you have so many nulls, this type of design will save you a great
deal of disk space, since rows in table 3 will only be added when actual
data exist.  You will find that this is more flexible in terms of retrieval
than a hierarchical or network design, as well.

Jan Harrington, sysop
Scholastech Telecommunications
seismo!husc6!amcad!stech!sysop