I'm undecided on how to implement something. Because the system that I'm building is holding student data, I have to implement a compartmentalized security model consisting of three levels: employees, districts, and TVIs (Teachers of the Visually Impaired). Employees can view and modify all data, districts can work with data only for students in for that particular district, and TVIs for the districts to which they are assigned, so TVIs can work with multiple district's data. I have an updateable view that matches SYSTEM_USER against a user table to find out of they're an employee (in which case they satisfy the WHERE condition as TRUE and proceed) or if they're a district or TVI they look up the district permission table to find out what districts they're permitted to view, and if that student is in that district, we're good.Functionally there is no difference in permissions for reading student data between a TVI and district user, pending further clarification of the business rules for this system. It is important to keep them differentiated outside of the system. All users are in one table, so when someone tries to access students, three (possibly four) tables are involved at the basic level: students, DBusers, and DBuserpermissions. (My next design iteration to experiment with is to transform the permissions table in to one record that will be updated by a regularly running SP while doing the initial data load and a trigger after the system is up and running)The current design (not yet finalized or implemented) has four bit flags: IsEmployee, IsDistrict, IsTVI, and IsInactive. Constraints limit values to Y/N and only one of the first three flags can be set. The IsDistrict and IsTVI fields have no business logic significance, they'll just apply to report listings. If IsInactive is set, the view's evaluation fails and no records are seen. Districts can add and remove TVIs to their district if they are set as active, only an employee can set or clear the IsInactive flag.I think the reason why I initially designed the implementation as bit fields is that I don't often use them. I could as easily use a lookup table to code their role. It would actually require an additional byte of space since I intend to keep the Inactive bit flag for easier trigger logic and a more clearly defined status. The additional byte is insignificant as we're expecting maybe 250 or so records, but the additional lookup table would require another page or three in the database, again, insignificant. But it would add another table to join to determine what districts are permitted for a user, so a slight hit there.So I'm a little undecided. The design using bit fields works just fine, though I haven't loaded the system with dummy records to see what performance plans look like. It is extremely unlikely that more user roles will be added to the system, though never say never. The design is fairly well agreed upon and fleshed out, and I don't know that changing the role to a lookup table clarifies things.Thoughts? If anyone's interested, I can post the code that does the compartmentalization (keeping in mind that it's just a proof of concept).
↧