Bevorzugte Datenbank-design-Methode für die Zuweisung von Benutzerrollen? (Hüte vs. Gruppen)

Ich habe mittlere MySQL-Datenbank mit einer primären "Personen" - Tabelle, die enthält grundlegende Informationen über jedes menschliche Wesen, verbunden mit dem Theater und Theater-Schule für die ich zuständig bin für den Erhalt und die Entwicklung einer Reihe von web-Anwendungen.

Einige Personen, die nur Kontakte - das ist Ihre "Personen" - Tabelle-Datensatz alle Informationen, die wir speichern über Sie. Viele andere jedoch haben zu können, übernehmen verschiedene Rollen für eine Vielzahl von Systemen. Von diesen, die meisten beginnen als Studenten. Einige beginnen als Mitarbeiter. Menschen, die Studenten können sich Praktikanten oder Interpreten, die Mitarbeiter können sich Studenten, Lehrkräfte, Mitarbeiter und Interpreten, etc.

Im wesentlichen, gibt es eine Vielzahl von verschiedenen "Hüte", die jede einzelne person haben mag zu tragen, um Zugriff auf und die Interaktion mit anderen teilen des Systems, sowie Informationen über Sie zur Verfügung gestellt, auf öffentlichen Seiten auf unserer Website.

Meine Wahl für die Umsetzung dieses Modells besteht darin, mehrere andere Tische, die repräsentieren diese "Hüte" - Tabellen, die meta-Informationen zur Ergänzung der basic - "person" - info, die alle verwenden die "Personen-id" als Ihre primäre Schlüssel. Zum Beispiel eine person, die ein Lehrer hat einen Eintrag in ein Lehrer-Tabelle, die seine oder Ihre kurze, biographische Informationen und rate zahlen. Alle Lehrer sind auch Angestellte (aber nicht alle Mitarbeiter sind Lehrer), das heißt, Sie haben einen Datensatz in der Tabelle Mitarbeiter, die Ihnen erlaubt, zu Unterwerfen, die Ihre Stunden in unserem payroll-system.

Meine Frage ist, was sind die Nachteile für die Umsetzung des Modells als solche? Die einzige andere Möglichkeit die ich mir denken kann ist, aufblasen, um den Personen-Tabelle mit Feldern, die leer und nutzlos für die meisten Einträge und müssen dann umständlich mit der Tabelle "Gruppen" zu denen Personen gehören, und dann die fast jeder Tabelle für jedes system eine person person_id foreign key-und dann davon abhängen, business-Logik, um zu überprüfen, dass die person_id verwiesen wird, gehört in die entsprechende Gruppe; Aber das ist dumm, nicht wahr?

Ein paar Beispiel-Tabelle Erklärungen Folgen unten, die hoffentlich zeigen sollte, wie ich bin derzeit dabei, alle diese zusammen, und hoffentlich zeigen, warum ich denke, es ist ein sinnvoller Weg, um ein Modell für die Realität der verschiedenen Situationen, die Systeme zu bewältigen haben.

Alle Vorschläge und Kommentare sind willkommen. Ich Schätze Ihre Zeit.

BEARBEITEN wenige befragte haben erwähnt, dass die Verwendung von ACLs für die security, die ich nicht erwähnt habe in meiner ursprünglichen Frage, ich bin in der Tat mit einem separaten ACL-Paket für fine-grained access control für den tatsächlichen Nutzern der verschiedenen Systeme. Meine Frage ist mehr über die best practices für die Speicherung von Metadaten über Menschen, die in der Datenbank-schema.

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;