This question isn’t about the database design of the RBAC system itself, but rather how to use this database in conjunction with the application specific database when that web application allows its users to submit content.
As it stands my RBAC should easily work for a simple back-end admin application, where staff can add and update records – an online store for example does not generally have user submitted content. The two databases can remain separate. However, I am not sure how I could reuse my RBAC design with a website/application that allows its users to submit content. I would have two User tables in two databases that require permissions for adding/updating records.
-
Do I incorporate my RBAC database into the website database and share the users table?
-
Do I keep the two separate?
-
Do something else?
If option 2 do I:
-
(A) duplicate the users from the website database into the RBAC user table
-
(B) create a relationship to the user table in the website database
-
(C) create a new RBAC system within the website database for the website users and have the separate RBAC for admin users?
A seems bad as I am duplicating data but seems pretty simple to implement. B seems like it will be difficult to create a relationship to two separate user tables. C is also duplication, but I can heavily customize this RBAC without impacting the “admin” RBAC.
I am basically wanting to make my RBAC system as reusable as possible and having application specific users being able to submit content is making things a bit difficult to get my head around.
This little RBAC system of mine is mostly a way for me to learn so please no generic “you should use framework x/y/z”. Using a term I discovered recently, I am somewhat a wheel nerd and like to reinvent them whenever I am curious! 🙂
I will be using MySQL and PHP for my sites, but this shouldn’t matter as it is the database design I am asking about here.
If my question isn’t clear please do let me know and I will to explain further. Thank you all for your time.
Not knowing your full implementation, I am leaning toward your first solution and only using one user table. The online application can then query the RBAC to determine if the user privledges. What is not clear to me is how many application attribultes would be needed and where they would be stored. If you do have user attribultes that need to be stored in the database then you can create a user table in the application with a foreign key reference to the RBAC to determine access privledges without storing that data in 2 places. How complex this would be depends on how many different places you can add and update users and their attributes. The physical database structure is very dependent on your business rules and architecture, but your logical design would be to keep the data in one table.