Re: database structure problem - advice please?

"Johnson" <johnson_at_spam.troll> wrote in message news:BhS_c.838$2H5.165_at_trndny07...
| Here's what I was doing, it is obviously stupid because i have exceeded
the
| "too many fields defined error"
|
| I have to create a database driven application that allows students to
| update the records of which classes they took, what grade they received,
and
| what semester they took the class in.
|
| I was using one database table, with some unique identifiers for each
| student. Then for each of the 50 classes they have to take, I had 4
fields
| each, one for whether they took it or not, one for the semester, one for
the
| year, one for the grade they received.
|
| So all in all I had 4x50 fields for the classes and then the various
unique
| identifiers.
|
| I just can't fathom how to simplify this problem. Anybody got any ideas?
|
|

you seem to be treating the relational database as if it were a big spreadsheet

you need to get at least a rudimentary understanding of data normalization, and basic entity/relationship analysis

get a good book on relational database design (Richard Barker's CASE Methodology Data Modelling or David Hayes Patterns in Data Modeling are still excellent references)

you will find that you need many, many more tables, likely:

STUDENTS -- 'master list' of students, likely with STUDENT_ID as the primary key
CLASSES -- 'master list' of classes, likely with CLASS_ID as PK SCHEDULED_CLASSES -- list of each occurrence of each class, likely with CLASS_ID plus CLASS_DATE or a system-assigned sequence number as PK STUDENT_CLASSES -- list that relates STUDENTS to STUDENT_SCHEDULED_CLASSES

don't just start creating these tables -- find out why 4 (or more) tables are needed by reading up on basic relational database theory

++ mcs Received on Mon Sep 06 2004 - 13:12:06 CEST