I have a table that contains user info. It has a primary key of userid. I have foreign key constraints in various other tables that reference the userid. These tables and database are for new applications.
Now, there are legacy apps also use a table of users. I need to make the legacy apps and new apps use the same list of users. The legacy apps use one database and the new apps use another, though on the same server. So, I've created a view in the new apps database that pulls in the necessary user columns from the legacy apps database.
Now, prior to this, and for development purposes only, I had a temp user table in the new apps database, and I had created foreign key constraints. Now, if I go with the view idea that I describe above, and remove the users table in the new apps database, I lose referential integrity enforced by the foreign keys, correct?
Questions: Is this a reasonable approach, to get the two sets of app to use the same set of user data? If I name the view the same as the user table and use the same column names, will this change be transparent? Is the loss of referential integrity a small price to pay? Any suggestions on how to better handle this?