数据库设计-哪个最适合？

Question

I'm a newbie messing around at designing a database. I want to create a database(using mysql) that contains employee information. Then I will write Web Client to display each employee profile. I so far the columns would be:

1) user id
2) first name
3) last name
4) email address
5) phone number
6) fax number
7) department(which will be like a category)

Would the best design be make items 1-6 columns in one table and then have the department column in it's own table(with a id column)? Or should I make all the items their own table, giving each table an extra id column....and would this be #1 normalization form?

Answer 1

只要您的所有列都不是多值的（例如，一个员工可以有多个部门），那么您的设计就是最佳的。

Answer 2

Your first solution is better, Items 1 to 6 should all be in a same table users . If you have more info on the department to store then you need to have a specific table departments which will have at least two columns : id and name and then in the users table you will have a department _id column that will store an id corresponding to a department in the departments table.

If you don't store any other info about the department, it might be better to store directly the department name in your users table to avoid having to JOIN tables everytime you retrieve or update information about a user.

Answer 3

User_Master
------------------

UserID - Primary Key
DeptID  - Foreign Key
FirstName
LastName
EmailID
PhoneNumber
FaxNumber


Dept_Master
----------------

DeptID - PrimaryKey
DepartmentName

Answer 4

Some further thoughts...

Don't forget to think about time. Can employees change departments, and are you interested in knowing this history? If that's the case you'll have to have a separate Departments table, and probably a Service (or something) table with EmployeeID, DepartmentID, StartDate and EndDate.

While thinking about changes that happen over time, do phone & fax numbers and email addresses fit with the employee or the position? If Janet in accounts lands the supervisor's job, does she get a different phone number in her new office, or is it one of those places where the telephone numbers move with the people. Ditto for email. Are addresses hr.officer@example.com or joe.smith@example.com? If the former in both cases you probably want to think about a Position table that keeps track of phone/fax/email (as well as paygrade, FT or PT etc) which has a DepartmentID foreign key.

Answer 5

If you are thinking in SQL, you definitely do well to think in (at least) first normal form. Multivalued columns are not only slow, they are also the first step towards chaos. This rule doesn't apply if you move towards a Nosql based solution.

Normal forms 2 through 5 help with populating the tables, but won't help you with your web client. The biggest thing you'll gain from full normalization is the guarantee that the database doesn't contradict itself. Things like two different names for the same department, in two different employee records (rows).

The big thing you need to add to your vision is views. You can use views to very good effect to make the data lok more the way you want a web page to look. This will make building the web client lots easier. There are areas where views aren't going to help either.

Take drop down lists. If as has been suggested, people can have more than one phone number, you might want to have a drop down list for phone numbers on the employee's page. This is basically a multivalued field, and views aren't especially helpful in that regard.

Answer 6

I think you can have department columns like department1, department2 etc. which will consist ids of each department. You can create another table called department which will have ids and department name. Now you can link the department ids in the first table to the second one. This will not mess if an employee is belonging to multiple departments.