数据库设计模式帮助2个实体

Question

Let us say I have two different entities on a site.

Teachers and Students .

They both login to the website.Right now I have the following tables

**Users**

 - id
 - email
 - password

**Students**

 - GPA
 - SAT
 - ACT
 - user_id references Users ID

**Teachers**

 - user_id references Users ID
 - classroom_no
 - salary
 - average_class_size

So when a Student registers I add a row in both the Users and Teacher table.

When a Teacher registers, I add a row in both the Users and Teacher table.

Is it better to just have ONE table Users with the following fields?

**Users:**

 - id
 - ACT
 - GPA
 - SAT
 - average_class_size
 - salary
 - classroom_no
 - role (0 = teacher 1 = student)

even though some rows would refer to teachers (and thus not use the ACT, SAT, GPA fields)

??

Thanks!

Answer 1

If you are not familiar with database normalization, please read this .

Unless performance is a serious issue, I would not look at using a single table for this structure. As your project goes one, you will more than likely add more fields to each role and possibly add more roles as well. It will become increasingly more difficult to maintain this.

I would actually go a step further and introduce another concept called role into your application, along with the appropriate data model to persist it.

Your tables should be:

users:
 - id
 - email
 - password

roles:
 - id
 - type

user_roles:
 - user_id
 - role_id

role_teacher:
 - user_id
 - classroom_no
 - salary
 - average_class_size

role_student:
 - user_id
 - GPA
 - SAT
 - ACT

Having a separate role table will let you separate your authentication table (users) from the rest of the data. This might become important if a user can be both a teacher and a student.

This should give you a basic understanding of how to structure your database.

You may find that you will begin to model some of the other concepts like classes in your system. So adding the appropriate tables may look something like:

role_teacher:
 - user_id
 - salary

classroom:
 - id
 - capacity

class:
 - id
 - name
 - teacher_id
 - classroom_id
 - start_date
 - end_date

class_enrollment:
 - class_id
 - student_id
 - enrollment_date
 - grade

Items like the teachers class room now moves to the class, allowing for the teacher to teach multiple classes (maybe you need to re-add the concept of "home room"). The teachers average class size then just becomes a calculation (though you may want to still store it for the sake of efficiency).

Hope this helps guide you in the right direction!

Answer 2

You should to go with Teachers and Students tables. Tables in database should reflect real world model (whenever it's possible of course). Merging everything into single User table brings very little value and introduces following issues:

• redundancy (teacher doesn't need ACT, GPA and so forth fields as you mentioned)
• complexity (you'll need extra logic to determine whether user is student or teacher)
• ambiguity (is user a system user, or real world person data, or just login information...?), term is far too generic

On top of that, I'd rename Users table to UserLogins - it indicates its purpose more clearly.

Answer 3

My feeling is that it's better the way you have it - you have to maintain both tables so that they're in sync, but you've better encapsulated the role of "User", "Student", and "Teacher" this way. It also leaves you a better maintenance footprint - what if you want to allow a "Parent" to log in with a reference to their child? What about a "Principal"? These are all users, but would quickly gum up the unified table.

Answer 4

There are a couple of ways to do this, but I think one table for users is the right way to go. You could have the empty columns - it doesn't look the greatest, but if it works for you, it would allow minimal coding to get the values you need.

Another option might be to have an attributes table { UserId, Attribute, Value }, then for example, you could have: User1 GMAT 710, User1 ACT 30, etc. So you could then get a list of all attributes for a user by select * from attributes where UserId = user.UserId or some such. More code overhead, much cleaner. This would also allow you to add more attributes in the future for whatever purpose, and keep your database the same.

Answer 5

If one teacher can take multiple classes, then your design fails, as the teacher table will have a multiple entries..

Instead Create one Teacher Table where we can store Teacher Table, create one intermedite table, where we can store the Teacher and His classes.

Similarly, Teacher and User table should be separate.. Let a separate User Table exists where we can store the Use details..