Preferred database design method for assigning user roles? (Hats vs. Groups)

Question

I have medium sized MySQL database with a primary \"persons\" table which contains basic contact information about every human being connected to the theatre and theatre school

Answer 1

I'm using an ACL package for fine-grained permissions on the site - the heart of my question is more about how to store the metadata for individuals who have different roles and build a few safeguards into the system for data integrity (such that a person must have a teacher record in order to be set as the teacher of a class - the foreign key constraint references the teacher table, not the person table).

Answer 2

For security I prefer to use Access Controls Lists (ACLs). With ACL's you have Principals (users or groups of users), Resources (such as a file, record or group of records) and Actions (such as read, update, delete).

By default nobody has any privilege. To grant a permission you add an entry like Bob has Read Access to File Abc.

You should be able to find code that helps you implement something like this. In Java the JAAS supports this method.

Answer 3

I went through a similar thing last year. There the question was: do we model our entities explicitly or generically? In your example, that would mean having entities/tables like teacher, student, etc with direct relationships between them or not.

In the end we went for a generic "Party" model. The Party model is as follows:

• A Party represents a person or organisation;
• Most Party types had a dependent table to store extra information depending on the party type eg Person, Organization, Company;
• Things like Student or Teacher are Party Roles. A Party may have any number of Party Roles. A Person may be both a Teacher and a Student, for example;
• Things like classes are handled as Party Role Relationships. For example, a relationship between a Teacher and Student role indicates a class relationship;
• Party Role Relationships can have subtypes for extra information. A Teacher-Student Relationship in your model is an Enrolment and that could have the extra attributes you're talking about;
• Parties don't have direct relationships with each other. Only Party Roles relate to each other; and
• For common groupings of information, we created views if it helped because the SQL can be a bit convoluted as the relationships are more indirect (eg there are three tables in between the Party entities for a Teacher and Student).

It's an extremely powerful model, one that is pretty common in CRM type systems. This model pretty much came from "The Data Model Resource Book: Volume 1", which is an excellent resource for such things.

Answer 4

The groups and hats models you describe are convertible, one to the other. There's no real worry about data loss. Specifically, the "master groups" table can be produced by outer joins of the "hat person" table with the various "hat detail" tables.

If you're using a "hat" model you need to make sure that a given "hat table" accurately encapsulates the unique characteristics of that hat. There's a lot less forgiveness there than with the groups model.

You'll probably want to set up a few views for common tasks if you go this way - for example, if somebody's typing into a field for "teacher name" and you want to pop up some autocompletes, having a view which is basically

SELECT firstName, lastName 
FROM persons 
INNER JOIN teachers ON persons.id = teachers.person_id 

will help enormously.

On a tangential note, one thing I've found to be useful is to call foreign keys by the same name as the primary key in their original table. That way you can just

INNER JOIN original_table USING (primary_key) 

in your FROM instead of monkeying with WHERE or ON equivalencies.

Answer 5

I used Party model before. I really solves most of the shortcomings.

Answer 6

yes, teachers are the only people who have a pay rate as such. That field should more accurately be called "classPayRate" - it's a special case for teacher employees. Non-teacher employees submit their total hours as a separate line item in our payroll system.