我是一个在设计数据库方面搞砸的新手。我想创建一个包含员工信息的数据库（使用 mysql）。然后我将编写 Web Client 来显示每个员工的个人资料。到目前为止，我的列是：
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 列在一个表中，然后将部门列放在它自己的表中（带有 id 列）？ 或者我应该让所有项目成为自己的表格，给每个表格一个额外的 id 列....这会是#1规范化形式吗？
【问题讨论】：
标签： mysql database database-design database-normalization
只要您的列都不是多值的（例如，一个员工可以有多个部门），那么您的设计就是最佳的。
【讨论】：
您的第一个解决方案更好，项目 1 到 6 应该都在同一个表中 users。
如果您有更多关于要存储的部门的信息，那么您需要有一个特定的表departments，其中至少有两列：id 和name，然后在users 表中，您将有一个@987654326 @_id 列将存储与departments 表中的部门对应的id。
如果您不存储有关部门的任何其他信息，最好将部门名称直接存储在 users 表中，以避免每次检索或更新用户信息时都必须加入表。
【讨论】：
User_Master
------------------
UserID - Primary Key
DeptID - Foreign Key
FirstName
LastName
EmailID
PhoneNumber
FaxNumber
Dept_Master
----------------
DeptID - PrimaryKey
DepartmentName
【讨论】：
一些进一步的想法......
不要忘记考虑时间。员工可以更换部门吗？您有兴趣了解这段历史吗？如果是这种情况，您将必须有一个单独的 Departments 表，并且可能是一个带有 EmployeeID、DepartmentID、StartDate 和 EndDate 的服务（或其他）表。
在考虑随时间发生的变化时，电话和传真号码以及电子邮件地址是否适合员工或职位？如果会计部门的珍妮特找到主管的工作，她是否在新办公室获得了不同的电话号码，或者是电话号码随人们移动的地方之一。电子邮件同上。地址是 hr.officer@example.com 还是 joe.smith@example.com？如果在这两种情况下都是前者，您可能需要考虑一个 Position 表，该表跟踪具有 DepartmentID 外键的电话/传真/电子邮件（以及工资等级、FT 或 PT 等）。
【讨论】：
如果您使用 SQL 进行思考，那么（至少）以第一范式思考肯定会很好。多值列不仅速度慢，而且是迈向混乱的第一步。如果您转向基于 Nosql 的解决方案，则此规则不适用。
普通表格 2 到 5 有助于填充表格，但不会帮助您使用 Web 客户端。您将从完全规范化中获得的最大好处是保证数据库不会自相矛盾。比如同一部门的两个不同名称，在两个不同的员工记录（行）中。
您需要为您的愿景添加的重要内容是视图。您可以使用视图来获得非常好的效果，以使数据看起来更像您希望网页的外观。这将使构建 Web 客户端更加容易。在某些领域，视图也无济于事。
获取下拉列表。如果按照建议，人们可以拥有多个电话号码，您可能希望在员工页面上有一个电话号码下拉列表。这基本上是一个多值字段，视图在这方面并不是特别有用。
【讨论】：
我认为您可以有部门列，如部门 1、部门 2 等，其中将包含每个部门的 ID。您可以创建另一个名为部门的表，该表将包含 ID 和部门名称。现在您可以将第一个表中的部门 ID 链接到第二个表。 如果员工属于多个部门，这不会造成混乱。
【讨论】：