Mysql Period Column and Junction Table

Question

Our technical adviser in school advised me to start creating master tables of entities before creating the junction tables. He also encouraged me to use composite PRIMARY KEYS instead of COMPOSITE UNIQUE keys for columns.

He told us to really spend most of the time with the database before programming the GUI so I need to make sure that the table design won't cause any problems.

So let's say,

ONE class has or belongs to MANY schoolyear = TRUE

ONE schoolyear has MANY classes = TRUE

Makes me think that having 3 tables,

(DESIGN 1):

Table 1: Classes

id PK
name
yearlevelId

Junction Table 2: SchoolYearClasses

id PK AI
classId -- FK REFERENCES classes(id)
schoolYearId -- FK REFERENCES schoolyear(id)

Table 3: SchoolYear

id PK AI
schoolYearStart
schoolYearEnd

is better than this

(DESIGN 2):

Classes

id PK AI
name
yearlevelId  -- FK REFERENCES yearLevel(id)
schoolyearId -- FK REFERENCES schoolyear(id)

SchoolYear

id PK AI
schoolYearStart
schoolYearEnd

I need some professional advice here because I'm sure you guys dealt with many systems involving periods. I know the design would affect the transaction inserts ill be creating as well as joins.

Which design is better? How can I go about inserting records if most of the columns are numerical (id)?

I'd appreciate any help.

Thanks.

Answer 1

For "junction" tables (to implement many-to-many mappings), I strongly disagree with using an AUTO_INCREMENT . You have a perfectly good composite PK, plus you need the pair of ids in reverse order in another INDEX . The end.

More on a good schema for M:N . This gives the "whys".

I agree with @Drew --

1. Work on the GUI for a while.
2. Then you will have a feel for what SELECTs are needed.
3. Sketch the SELECTs based on both of your designs. It may become obvious that one schema is better.
4. Then finalize the schema design.
5. Six months later improve the schema. (Yes, you will find that the "final" design was not all that good.)