在 MySQL 表关系设计方面需要帮助

Question

I'm creating web application for my friend, a tutor school system. Now, I'm having a problem about designing table to store teacher record. Here is the scenario...

1. We have to create course first
2. Then we add teacher to course (Let's say that we already have teacher record stored in teacher table), each course can have more than one teacher and each teacher can teach more than one course.
3. Everytime teacher come to teach, we keep record. Each teacher teaching at a course more than once.
4. By the end of the month, we pull all teaching record out and calculate money we have to pay

This is my current tables

// Course Table
course_id (PK)
...
...

// Teacher Table
teacher_id (PK)
...
...

// Course_teacher
course_id (FK: course.course_id)
teacher_id (FK: teacher.teacher_id)

The problem is I can't add fee to the course_teacher table because at the first moment I add teacher to this course, there is no teaching happened yet. If I add column "fee" and "date" to this table, data will be like...

1,1,null,null (This record add before the course is starting, which I don't like having null field(s))
1,1,50,2011-06-12 (This record add at the first time teacher is teaching)
1,1,50,2011-06-19 (This record add at the second time teacher is teaching)
...

I was thinking about adding one more table like

//Teaching_fee
course_id (FK: course.course_id)
teacher_id (FK: teacher.teacher_id)
fee
paid_status
date

If I do so,
1. course_teacher will keep information of teacher related to course
2. teaching_fee will keep information of the teaching fee

It should works. But, something in my mind is telling me that this is not right. Those two tables are similar to each other even their creation purpose are different.

Any suggestion?

Edit 1 : Just came up with one idea. What if do this way

//Course_teacher Table
id (PK)
course_id (FK: course.course_id)
teacher_id (FK: teacher.teacher_id)

//Teaching_fee Table
id (FK: course_teacher.id)
fee
paid_status
date

Final solution : I decided to do as btreat suggested

// Course Table
course_id (PK)
...
...

// Teacher Table
teacher_id (PK)
...
...

// Course Teacher Table
course_teacher_id (PK) // synthetic
teacher_id (FK)
course_id (FK)
...
...

// Teacher Fee Table
course_teacher_id (PK)
date_paid (PK)
fee
paid_status
...
...

Answer 1

This would probably be more normal.

TABLE RateCards uid fee paid_status date

TABLE Teacher_RateCards uid RateCardId TeacherId

Answer 2

If you use a 'teaching_fee' table rather than 'course_teacher', I wouldn't be concerned about having a null value for fee as long as the business logic in the application knows how to interpret null (ie the fee has not yet been paid).

However, based on your description, it sounds like a record of each time a teacher is paid for a course and the date that payment was made needs to be kept around? If that's the case, you will definitely need a 'teaching_fee' table where the combination of teacher_id, course_id and date_paid forms a unique key. If separately, you need to know all of the unique teacher / course combinations, you can query the 'teaching_fee' table. However, if the teacher / course combination doesn't get created in 'teaching_fee' until the teacher is paid, having a separate 'course_teacher' table would be fine.

To avoid your dissatisfaction with the denormalizing (repeating) course / teacher combinations, another alternative would be to structure your tables like this:

// Course Table
course_id (PK)
...
...

// Teacher Table
teacher_id (PK)
...
...

// Course Teacher Table
course_teacher_id (PK) // synthetic
teacher_id (FK)
course_id (FK)
...
...

// Teacher Fee Table
course_teacher_id (PK)
date_paid (PK)
fee
paid_status
...
...