我有一个中等大小的MySQL数据库,带有一个主要的"人员"表,其中包含有关连接到剧院和剧院学校的每个人的基本联系信息,我负责维护和开发许多Web应用程序.
有些人只是联系人 - 也就是说,他们的"人"表记录是我们需要存储的所有信息.许多其他人必须能够为各种系统承担不同的角色.其中,大部分都是以学生身份开始的.一些人从员工开始.作为学生的人可以成为实习生或表演者; 员工可以成为学生; 所有教师都是员工和表演者等.
从本质上讲,它们是各种不同的"帽子",任何个人可能必须佩戴这些"帽子"才能访问系统的不同部分并与之交互,并且在我们网站的公共页面上提供有关它们的信息.
我实现这个模型的选择是有几个表代表这些"帽子"的表 - 包含元信息的表,以补充基本的"人"信息,所有这些都使用"人物"id作为他们的主键.例如,作为教师的人在教师表中具有包含他或她的简短传记信息和工资率的记录.所有教师也是员工(但并非所有员工都是教师),这意味着他们在员工表中有一个记录,允许他们将工作时间提交到我们的工资单系统中.
我的问题是,实施模型有什么缺点？我能想到的唯一另一个选择是为人员表填充对于大多数条目都是空的和无用的字段,然后有一个人们可以归属的"组"的繁琐表格,然后几乎每个表都有系统有一个人person_id外键然后依赖业务逻辑来验证引用的person_id属于适当的组; 但那是愚蠢的,不是吗？
下面是一些示例表声明,希望能够展示我目前如何将所有这些结合在一起,并希望说明为什么我认为这是一种更合理的方式来模拟系统必须处理的各种情况的现实.
欢迎提出任何建议和意见.我很感激你的时间.
编辑一些受访者提到使用ACL进行安全性 - 我在原始问题中没有提到我实际上使用单独的ACL包来为不同系统的实际用户进行细粒度访问控制.我的问题更多的是关于在数据库模式中存储有关人员的元数据的最佳实践.
CREATE TABLE persons (
`id` int(11) NOT NULL auto_increment,
`firstName` varchar(50) NOT NULL,
`middleName` varchar(50) NOT NULL default '',
`lastName` varchar(75) NOT NULL,
`email` varchar(100) NOT NULL default '',
`address` varchar(255) NOT NULL default '',
`address2` varchar(255) NOT NULL default '',
`city` varchar(75) NOT NULL default '',
`state` varchar(75) NOT NULL default '',
`zip` varchar(10) NOT NULL default '',
`country` …