3 ms·
It can be really nice for enterprise web apps. One might have thousands of users organized into a handful of departments with different authorizations, some of
by rch 11y ago
It can be really nice for enterprise web apps. One might have thousands of users organized into a handful of departments with different authorizations, some of which have their own DBAs and developers. Solid testing on the application side is important, of course.
- rst 11y agoIf the database roles correspond to departments, and authorizations at a department level, this sort of thing can be quite useful. (e.g., in a hospital, designating certain rows as visible only to the psychiatry department, in a way that developers within other departments can't screw it up.) But establishing a DB role for every distinct person within a department gets awkward very fast, particularly if permissioning requirements have a bit of business logic associated with them (e.g., "this row can be updated by the user designated in the row itself as "owner", and is visible to both them and anyone designated in this other table over here as their assistant...") So, you'll often still need additional permissioning logic within the webapp regardless.
- rch 11y agoYes, exactly. Roles would generally be by department, or in an application/department matrix. Your hospital example is spot on, and in finance a department might be a trading group.