人->详细数据库结构
我有一个域模型：
员工：身份证、名字、姓氏、性别、出生日期。
办公室：员工、工作站、办公室名称等。
联系人：员工、手机、电子邮件等...
但我不确定我当前的数据库结构。如何正确：员工表有一个 PK EmployeeID，办公室和联系人表有自己的 ID 和对员工表的引用，或者员工表有自己的 EmployeeID，并且还通过拥有 OfficeID 和 ContactID 来保留对办公室和联系人的引用？
I have a Domain model:
Employee: Id, FirstName, LastName, Sex, BirthDate.
Office: Employee, WorkStation, OfficeName, etc..
Contacts: Employee, MobilePhone, EMail, etc...
But I`m not sure about my current database structure. How is right: Employees table has a PK EmployeeID, and the Offices and Contacts tables has their own IDs and reference to Employees table, OR Employees table has its EmployeeID and also keeps references to Offices and Contscts by having OfficeID and ContactID?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为了保持合理的正常形式，您的员工应咨询办公室。
假设联系人关系是员工拥有一组联系人，并且没有其他员工共享这些联系人，则正确的关系应该是联系人引用该员工。
员工：empid、officeid
办公室：officeid
联系人：empid、contactid
To be in a reasonable normal form, your employees should refer to the office.
Assuming the relationship of contacts is employees have a set of contacts and no other employee shares those contacts, the proper relationship should be contacts refer to the employee.
Employee: empid, officeid
Office: officeid
Contacts: empid, contactid
如果 Office 和 Contact 表中的数据只是增强有关 Employee 的信息，我会使用 EmployeeID 作为 Employee 的主键和外键。该模型模拟了 1 到 0..1 的关系。
员工：员工 ID 作为主键
办公室和联系人：员工 ID 作为员工的主键和外键
If data in Office and Contact table just enhance information about Employee, I would use EmployeeID as primary key and foreign key to Employee. That models 1 to 0..1 relation.
Employee: EmployeeID as primary key
Office and Contacts: EmployeeID as primary key and foreign key to Employee
您的模型没有明确说明员工、办公室和联系人之间的关系。
具体来说，这些关系是一对一、一对多还是多对多？一旦您对想要建模的关系进行了分类，数据库的外键结构就会变得清晰。
Your model is not explicit about the relationships between Employees, Offices, and Contacts.
Specifically, are these relationships one-to-one, one-to-many, or many-to-many? Once you've catalogued the relationships you want modeled, the foreign key structure of your database will become clear.