0

那个问题:

数据库结构

总结:

  • 我的 CRUD 是:客户、员工和分支机构。
  • Customers 和Employees 与一Person、一Individual(与个人相关的字段)和一User(用于登录目的)相关联。所以Individuals 和Users 总是与一个人CustomerEmployee人有关。
  • Branches 与一Person和一相关联Company(与公司人员相关的字段)。所以Companys 总是与一个Branch人有关。他们没有用户,因为他们隶属于该数据库所代表的公司——他们的员工可以在应用程序中进行身份验证。
  • 一个Employee属于一个Branch。ABranch有零个或多个Employees。(是的,图表不正确,对不起!)
  • 目前我正在使用一个位来区分Employee角色 - 我的员工拥有操作和管理权限。角色权限进入代码本身,在这里您可以意识到客户也有自己的角色......有什么建议可以实施更好(和简单)的方式来管理客户和员工的角色吗?

我应该如何更改错误的 3NF 结构以实现设计良好的单表继承,以便更好地使用 MVC 模式?

我试着简化了一下,现在我完成了这个新结构:

新的数据库结构

我还能改进吗?在哪里?你会如何建模?

4

1 回答 1

0

仅当您具有正常-低基数(唯一性较少/重复次数较多)时,才值得为城市创建一个新表。因此,根据您的用户,您将不得不自己决定。另一方面,您可以拆分地址表和电话号码表。

根据您存储的有关员工和客户的信息类型,您可以只有一个字段来指示此人是员工还是客户,或者可以有两个单独的表。

如果我们谈论角色,它们通常表示员工的权限/职位/可访问性。即常规,P/T,经理。您可以为每个组/角色开发内容的访问级别和可见性。

从 Person 中取出所有个人详细信息并将它们存储在新表中。(只是好奇......你真的需要nickname字段吗?磁盘 I/O 是任何应用程序的最大瓶颈之一)将个人详细信息与专业详细信息和 ID 分开。

说到Branch,你确定任何时候都只有一个联系人吗?通常,在商业世界中并非如此。但是一个分支机构/人在任何给定时间都只有一个地址,所以在这里你单独的地址表会很有帮助。

一般来说,很难提出一个结构。一个好的设计总是基于业务规则。

于 2012-10-04T18:08:40.773 回答