I’ve got a PHP/HTML/Javascript driven front-end for a MySQL database which archives different files/papers for our office (kind of an electronic index for physical paperwork).
The users want to be able to have permissions on each of these entries; for instance HR complaints need to be indexed, but should not be viewable by all users of the database.
The user heirarchy is two-tier. Each user is a member of one OR MORE distribution lists (similar to an Email list). When a file is indexed, the user choses the permissions for others: for instance he/she can select the following for a sample HR complaint:
List | Permission
`````````````````````````````````
HR Dept | Read/Write
Board Members | Read
John Smith | Read/Write
Mary Smith | Read
and should be invisible to anybody else. Now I’ve tried several things to implement this, the most recent being a relations table which relates the following:
User 1->Many DistributionList // Assoc the user to some lists
Permission 1->Many DistributionList //Indicates level of permission that the list has
Permission 1->Many User //Indicates level of permission for each user
However the permission table contains a row for each file for each permission, which, given a few thousand files and ~50-60 lists/users, means a few hundred thousand entries. Since this index will not be flushed often (maybe flush files older than 50 years) that number could skyrocket. Not to mention that the queries are somewhat complicated, and take a decent amount of time (~1 second for the SQL request) for only a couple hundred files.
Is there a more efficient way to create this sort of User based stuff? Is it possible instead to make users in SQL itself with these permissions and let the connection handle these things?
tl;dr: What is the best way to put read/write/invisible permissions on entries in MySQL using PHP, Javascript, HTML and PHPMyAdmin?
If there are not many groups (64 max) you could use a SET of permissions for each file (1 extra column).
http://dev.mysql.com/doc/refman/5.0/en/set.html
So each file could have one column denoting which groups it belongs to, which can be expanded as the systems grows.
You could also add a second column if you want to go beyond 64, but that would require more complex queries (keeping departments separate would help here, HRgroups, Boardgroups etc..)
You could also add exceptions to specific users or create another group. But as you say one associating entry per file/user is the best your going to get.