February 8, 2011 at 12:00 pm
hi
I think probably you mean the sequence in which the script will be executed .
and hence you are concerned about
ALTER TABLE [dbo].[UserInfo] WITH CHECK ADD CONSTRAINT [FK_UserInfo_Country] FOREIGN KEY([CountryID])
REFERENCES [dbo].[Country] ([CountryID])
when i have not as yet created the Country table.
If that is your concern, I have just generated this script from two table , one by one to just show you.
Correct me if i am wrong
Thank you so much for all your time and effort. So i have now decided to go ahead with this relationship. and yes i have many more such relations in UserInfo with other tables and i will put non clustered indexes on all.
By i means i beleive its a good way to go in terms of Data Integrity and Performance.
What is your final word
Zubair
February 8, 2011 at 12:05 pm
Yes you're right on the script part.
Like I said I NEVER leave the keys out of the dev phase.
And then I'm good enough at tuning that I don't need to take 'em. So I'd start there.
One more thing to consider is that those FKS are self documenting the DB for you. It's much easier to hire a new guy and let him play with the db rather than explaining all the littles joins one at a time.
February 8, 2011 at 12:36 pm
Ninja's_RGR'us (2/8/2011)
Yes you're right on the script part.Like I said I NEVER leave the keys out of the dev phase.
And then I'm good enough at tuning that I don't need to take 'em. So I'd start there.
One more thing to consider is that those FKS are self documenting the DB for you. It's much easier to hire a new guy and let him play with the db rather than explaining all the littles joins one at a time.
Thanks Ninja,
I will just like to trouble a little more, I hope you will bear me while I try and solve the problem.
"Like I said I NEVER leave the keys out of the dev phase. And then I'm good enough at tuning that I don't need to take 'em. So I'd start there." .
Do you mean that during your development process you always put constraints to ensure data integrity during development stages and Once it comes to tuning the database you decide whether to keep the constraint or remove it .
One more thing to consider is that those FKS are self documenting the DB for you. It's much easier to hire a new guy and let him play with the db rather than explaining all the littles joins one at a time.
I could not understand what you mean by the above statement.
Thanks
Zubair
February 8, 2011 at 3:08 pm
I've always kept the FKs, tho I've seen systems work well without 'em (microsoft application).
When you use the diagrams of SMSS, the FK will allow you to see the relations between tables and joins. If lose that if you drop them.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply