用于分配用户角色的首选数据库设计方法？(帽子与团体)

Question

我有一个中等大小的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`       varchar(75) NOT NULL default '',
    `phone`         varchar(30) NOT NULL default '',
    `phone2`        varchar(30) NOT NULL default '',
    `notes`         text NOT NULL default '',
    `birthdate`     date NOT NULL default '0000-00-00',
    `created`       datetime NOT NULL default '0000-00-00 00:00',
    `updated`       timestamp NOT NULL,
    PRIMARY KEY (`id`),
    KEY `lastName` (`lastName`),
    KEY `email` (`email`)
) ENGINE=InnoDB;

CREATE TABLE teachers (
    `person_id`     int(11) NOT NULL,
    `bio`           text NOT NULL default '',
    `image`         varchar(150) NOT NULL default '',
    `payRate`       float(5,2) NOT NULL,
    `active`        boolean NOT NULL default 0,
    PRIMARY KEY (`person_id`),
    FOREIGN KEY(`person_id`) REFERENCES `persons` (`id`)
        ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;

CREATE TABLE classes (
    `id`            int(11) NOT NULL auto_increment,
    `teacher_id`    int(11) default NULL,
    `classstatus_id` int(11) NOT NULL default 0,
    `description`   text NOT NULL default '',
    `capacity`      tinyint NOT NULL,
    PRIMARY KEY(`id`),
    FOREIGN KEY(`teacher_id`) REFERENCES `teachers` (`id`)
        ON DELETE RESTRICT ON UPDATE CASCADE,
    FOREIGN KEY(`classstatus_id`) REFERENCES `classstatuses` (`id`)
        ON DELETE RESTRICT ON UPDATE CASCADE,
    KEY (`teacher_id`,`level_id`),
    KEY (`teacher_id`,`classstatus_id`)
) ENGINE=InnoDB;

CREATE TABLE students (
    `person_id`     int(11) NOT NULL,
    `image`         varchar(150) NOT NULL default '',
    `note`          varchar(255) NOT NULL default '',
    PRIMARY KEY (`person_id`),
    FOREIGN KEY(`person_id`) REFERENCES `persons` (`id`)
    ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;

CREATE TABLE enrollment (
    `id`                int(11) NOT NULL auto_increment,
    `class_id`          int(11) NOT NULL,
    `student_id`        int(11) NOT NULL,
    `enrollmenttype_id` int(11) NOT NULL,
    `created`           datetime NOT NULL default '0000-00-00 00:00',
    `modified`          timestamp NOT NULL,
    PRIMARY KEY(`id`),
    FOREIGN KEY(`class_id`) REFERENCES `classes` (`id`)
        ON DELETE RESTRICT ON UPDATE CASCADE,
    FOREIGN KEY(`student_id`) REFERENCES `students` (`id`)
        ON DELETE RESTRICT ON UPDATE CASCADE,
    FOREIGN KEY(`enrollmenttype_id`) REFERENCES `enrollmenttypes` (`id`)
        ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;

Answer 1

我去年经历过类似的事情.那里的问题是:我们是明确地还是一般地模拟我们的实体？在您的示例中,这意味着拥有教师,学生等实体/表格,它们之间是否存在直接关系.

最后我们选择了一个通用的"派对"模型.党的模式如下:

• 一个党的代表的个人或组织;
• 大多数Party类型都有一个依赖表来存储额外信息,具体取决于派对类型,例如Person,Organization,Company;
• 像学生或老师这样的事情是党的角色.一方可能有任意数量的派对角色.例如,一个人可以是教师和学生;
• 像类角色关系一样处理类.例如,教师和学生角色之间的关系表示阶级关系;
• 派对角色关系可以有子类型以获取额外信息.模型中的师生关系是一个注册,可能有你正在谈论的额外属性;
• 缔约方之间没有直接关系.只有党派角色相互关联; 和
• 对于常见的信息分组,我们创建了视图,如果它有帮助,因为SQL可能有点复杂,因为关系更间接(例如,教师和学生的Party实体之间有三个表).

它是一个非常强大的模型,在CRM类型系统中很常见.这个模型几乎来自"数据模型资源手册:第1卷",这是一个很好的资源.

Answer 2

教师是唯一有工资的“人”吗？这样做可能会限制您的设计。您可能想要做的是拥有一个属性表来存储“人”的附加属性。这将允许将来进行修改。