我对数据库设计感到困惑.我是其中一家公司的开发人员,我和我的老板就数据库设计中的以下问题进行了讨论.我必须处理的数据库设计的一部分包含两个表:
Employees Table: Username, Name, JobTitle, OrganizationCode
Organizations Table: OrganizationCode, Name...
这两个表将照顾公司的所有员工,部门,部门和单位.其他开发人员设计的大多数数据库都是以这样的方式设计的,这两个表之间没有任何关系.
对我来说,我告诉我的老板,最好在这两个表之间建立关系(这意味着它OrganizationCode是Organizations表主键的外键).因为它很容易强制执行约束,完整性以及编写查询.
他没有给我正当理由就拒绝了.我们的部门拥有2000多名员工,公司员工人数超过50000人.所以,我认为,他建议将承担着巨大的空间设计,它是将是困难的,从应用开发的前瞻性处理.
你有什么推荐的人？
你和你的老板都需要了解分析和设计之间的区别.两个表之间关系的设计从属于现实世界中的主题,以及对数据库的信息要求.
当您从数据角度分析主题(所谓的"现实世界")时,您将整个主题空间划分为这些实体之间的实体和关系.然后,将每个值作为属性的实例存储在数据库中.每个属性描述实体或关系的某些方面.每个属性还有一个域,该域是该属性的可能值集.所有这些构成了概念数据模型,并且发现了它的特征,而不是发明的.
然后,当您进行数据库设计时,可以根据您对实体,关系和属性的了解来设计列,表和外键.在给出概念模型和其他一些细节的情况下,您当然需要知道如何制作出好的设计.
那么,在你的情况下,对象是什么样的？员工在部门工作吗？那是一种关系.一个部门可以有很多员工在其中工作.员工可以在多个部门工作吗？如果是,那么你就有了多对多的关系.如果是这种情况,您将需要一个包含两个外键的联结表.如果没有,那么您的设计将充分反映多对一关系.
通过这种方式表达问题,就主题而言,您可以与老板就现实世界的结构达成共识.然后,您可以就外键如何帮助代表现实达成共识.或者你的老板可能满足于将数据库(重新)设计留给你,只要他/她保留对概念模型的否决权.