[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 168
  • Last Modified:

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?  
0
HLRosenberger
Asked:
HLRosenberger
  • 3
  • 2
1 Solution
 
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
 
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
Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

 
HLRosenbergerAuthor Commented:
Not linked.  Two databases on the same server.
0
 
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
 
HLRosenbergerAuthor Commented:
Thanks!
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now