I am developing 3-4 interdependent programs. Call them foo bar baz and auth. I want them to be independent of each other. Imagine if I were to license out each program to other companies. Some companies may want foo and bar, others may just want baz, etc. It also seems like good practice to keep auth independent as well.
Context: auth is taking care of authentication for all of the systems. The main users table in auth has user_id, email, password, first, last
foo has a users table as well which has specific fields for the application: user_id, role_id, etc.
Each system has its own database. In the past I have created a foreign key from each application to the auth db. I removed update permissions from the other dbs but granted select access to certain relevant fields. This seems like a bad solution because it creates a tight dependency, but it allowed me to normalize the db so that I didn't have to store the users name and email in the foo, bar, or baz databases.
Would it be better to store the information in all of the databases? Or would it be better to store the Auth Id in foo bar and baz and use an api to get the user info using the authId?
Similarly, I might have customers in all 3 systems. Sure it seems bad to create a dependency into an auth db, but what about the customer dbs across all 3 of them?
Or is the best solution to have one central db. One users table.
Other Suggestions?
foo bar
examples are often too abstract to be good illustrations. – Robert Harvey May 15 '15 at 2:35