Question

我是一个设计数据库的新手。我想创建一个包含员工信息的数据库（使用mysql）。然后我将编写Web客户端以显示每个员工配置文件。到目前为止我的专栏是：

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)

最好的设计是在一个表中创建项目1-6列，然后在它自己的表中使用department列（带有id列）吗？或者我应该将所有项目都设置为自己的表格，为每个表格提供一个额外的id列....这会是＃1规范化形式吗？

Answer 1

只要您的列没有多值（例如，员工可以拥有多个部门），那么您的设计就是最优的。

Answer 2

您的第一个解决方案更好，第1至第6项应该都在同一个表users中。如果您有关于要存储的部门的更多信息，那么您需要有一个特定的表departments，其中至少有两列：id和name，然后在users中}表，您将有一个department _ id列，用于存储与departments表中某个部门对应的ID。

如果您不存储有关该部门的任何其他信息，最好直接将部门名称存储在users表中，以避免每次检索或更新有关用户的信息时都必须加入表。

Answer 3

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

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


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

DeptID - PrimaryKey
DepartmentName

Answer 4

进一步的想法......

不要忘记考虑时间。员工可以更换部门，您是否有兴趣了解这段历史？如果是这种情况，你将需要一个单独的Departments表，可能还有一个Serviceee，DepartmentID，StartDate和EndDate的服务（或其他）表。

在考虑随着时间的推移发生的变化时，请做手机和电话。传真号码和电子邮件地址是否适合员工或职位？如果珍妮特在账户中找到了主管的工作，她是否在她的新办公室获得了不同的电话号码，或者是电话号码随人们移动的地方之一。同上电子邮件。地址是hr.officer@example.com还是joe.smith@example.com？如果在前两种情况下你可能想要一个跟踪电话/传真/电子邮件（以及paygrade，FT或PT等）并具有DepartmentID外键的位置表。

Answer 5

如果您正在考虑SQL，那么（至少）第一个普通形式的思考肯定会很好。多值列不仅速度慢，而且也是迈向混乱的第一步。如果您转向基于Nosql的解决方案，则此规则不适用。

普通表单2到5有助于填充表格，但不会帮助您使用Web客户端。您将从完全规范化中获得的最大好处是保证数据库不会自相矛盾。对于同一部门的两个不同名称，在两个不同的员工记录（行）中。

您需要为愿景添加的重点是观点。您可以使用视图获得非常好的效果，使数据更像您希望网页的外观。这将使构建Web客户端变得更容易。有些地方的观点也无济于事。

下拉列表。如果已经建议，人们可以拥有多个电话号码，您可能希望在员工页面上有一个电话号码下拉列表。这基本上是一个多值字段，在这方面，视图并不是特别有用。

Answer 6

我认为您可以拥有department1，department2等部门列，其中包含每个部门的ID。您可以创建另一个名为department的表，该表将具有ID和部门名称。现在，您可以将第一个表中的部门ID链接到第二个表。如果员工属于多个部门，这不会搞乱。

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

6 个答案: