Moving from a table to a view

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?  
LVL 1
HLRosenbergerAsked:
Who is Participating?
 
JestersGrindCommented:
It's not a bad way to go.  It would also be nice if you could have cross database foreign key relationships, then you wouldn't need the view, but that's not an option.  You're exactly right, though.  You are sacrificing referential integrity.  To know the impact of this, you would have to look at everything that references the view.  The danger is that something could be modified that would violate that constraint.  Like a using a userid that isn't in the view.  Most likely, you are probably safe.

Another way to go is to make the view a table so that you can still have referential integrity.  To implement this, you would have to create a stored procedure to synch up the data.  And then run that procedure periodically through a job.  If you only insert and update data in the original users table, this should be fairly easy.  I'm assuming that you set some sort of active flag instead of deleting.  That's always how I setup my users tables because you can't delete users without deleting all of the data associated with them.

Hope this makes sense.  If not, please ask questions.

Greg
0
 
Bob LearnedCommented:
I am not sure that I completely understand your question.  Referential integrity is enforced at the table level, and I don't quite understand what changes you would be making to the tables.
0
 
HLRosenbergerAuthor Commented:
I would lose the Referential integrity for the userid's in the new database because I'd now create a view in the new database that would pull in the data from the old database.

The new database has other tables that currently have foreign keys to the temporary user table - which would go now go away and be replaced by the new view.  

Did I articulate this properly?

 
0
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

 
Bob LearnedCommented:
Are you saying that you have a linked server, and the view would be referencing data from both databases, without foreign key relationships?
0
 
HLRosenbergerAuthor Commented:
Not linked.  Two databases on the same server.
0
 
HLRosenbergerAuthor Commented:
Thanks!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.