April 5, 2012 at 9:36 pm
Comments posted to this topic are about the item Foreign key
Igor Micev,My blog: www.igormicev.com
April 5, 2012 at 10:57 pm
Answer sounds ambigous. Please clarify on the answer explanation.
M&M
April 6, 2012 at 2:02 am
Another tricky and bad worded question.
In the earlier versions of any DBMS, the foreign key was implemented thru triggers.
So the answer should be "YES, implemented by trigger."
Or change the question: a CONSTRAINT FOREIGN KEY could reference a table in another database?
Example:
ALTER TABLE XXX ADD CONSTRAINT FK_XXX_NNN FOREIGN KEY(a)
REFERENCES ANOTHERDB.dbo.NNN(a)
In this case the answer is NO.
April 6, 2012 at 3:02 am
Be careful!
The question did not mention SQL Server.
I believe that you can use a trigger in Oracle (wash your mouth out, Spencer!) to permit a foreign key to reference a remote or external database.
Only when we get to the explanation does SQL Server come into it.
(OK, before hundreds of respondents criticise me, I know what this website is called.)
Happy Easter!
Ken.
You never know: reading my book: "All about your computer" might just tell you something you never knew!
lulu.com/kaspencer
April 6, 2012 at 3:13 am
I flipped a coin and ended up lucky. Two answers can both be considered correct.
No, a foreign key constraint can not be created across databases. If you refer to the actual constraint of that name, as supported by SQL Server.
Yes, a foreign key constraint can be enforced across databases using triggers. If you refer to the actual meaning of the constraint in a logical model.
With just the "yes" and "no" answers and a slight rewording of the question to prevent the ambiguity, this would have been a great question. With this wording *and* the presence of both "no" and "yes, with a trigger" in the answers, the question tries to trick people into giving the wrong answer. I assume that this was not the intention of the author - but it does have that effect!
April 6, 2012 at 4:12 am
Hi All,
Yes, I agree with some members that the question is a bit ambiguous, but I put the third option to make the question “ambiguous” i.e. to make you think a bit more about. Just review the first note on the following link http://msdn.microsoft.com/en-us/library/ms175464.aspx.
I also put a sqlservercentral post to clarify the third option of this QotD: http://www.sqlservercentral.com/Forums/Topic157655-8-1.aspx#bm157658
Yes, the question is about SQL server by default, if it was for Oracle or another database, it would have been appointed.
The question is inspired by practice, and I didn’t have any intention to put ambiguity in answering it.
Thank You
IgorMi
Igor Micev,My blog: www.igormicev.com
April 6, 2012 at 5:28 am
Igor, thanks for the question. Made me think. Maybe it was easier for me, as I answered the question in my head, before being presented with the three possible answers.
For those of you for which it will be a holiday, Happy Easter.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
April 6, 2012 at 7:22 am
Hugo Kornelis (4/6/2012)
I flipped a coin and ended up lucky. Two answers can both be considered correct.No, a foreign key constraint can not be created across databases. If you refer to the actual constraint of that name, as supported by SQL Server.
Yes, a foreign key constraint can be enforced across databases using triggers. If you refer to the actual meaning of the constraint in a logical model.
With just the "yes" and "no" answers and a slight rewording of the question to prevent the ambiguity, this would have been a great question. With this wording *and* the presence of both "no" and "yes, with a trigger" in the answers, the question tries to trick people into giving the wrong answer. I assume that this was not the intention of the author - but it does have that effect!
+1. I went with no because I don't consider enforcing referential integrity through a trigger a foreign key, but the question could have been worded better to make it less ambiguous.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 6, 2012 at 7:36 am
There are 3 options(Yes, No, Yes by using triggers) and you can check only one of them.
So if it will be Yes by using triggers than also Answer Yes is correct. So Third option can't be correct, because in that case the first option is also correct.
So it reduce options on No and "Yes but without using triggers" (Yes-Yes by using triggers).
And from those 2 options it was easy to choose the correct one.
April 6, 2012 at 7:37 am
Ugh, should have gone with my first impulse, but then I thought it was a trick since you can create a foreign key type of relationship across databases with triggers.
April 6, 2012 at 7:48 am
Jack Corbett (4/6/2012)
Hugo Kornelis (4/6/2012)
I flipped a coin and ended up lucky. Two answers can both be considered correct.No, a foreign key constraint can not be created across databases. If you refer to the actual constraint of that name, as supported by SQL Server.
Yes, a foreign key constraint can be enforced across databases using triggers. If you refer to the actual meaning of the constraint in a logical model.
With just the "yes" and "no" answers and a slight rewording of the question to prevent the ambiguity, this would have been a great question. With this wording *and* the presence of both "no" and "yes, with a trigger" in the answers, the question tries to trick people into giving the wrong answer. I assume that this was not the intention of the author - but it does have that effect!
+1. I went with no because I don't consider enforcing referential integrity through a trigger a foreign key, but the question could have been worded better to make it less ambiguous.
That was the exact same line of thinking I had. Basically you can simulate a foreign key via triggers but it is NOT actually a foreign key. In that case it is more of a business rule and can be sidestepped by disabling the trigger temporarily. The same cannot be said for a foreign key constraint. You can't just disable the constraint and turn it back on with bad data like you could with a trigger style implementation.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 6, 2012 at 8:22 am
Very tricky, I missed it since you can enforce it through a trigger and I thought that was where the author was headed. That's what I get for assuming I guess.
April 6, 2012 at 8:24 am
Sean Lange (4/6/2012)
Basically you can simulate a foreign key via triggers but it is NOT actually a foreign key. In that case it is more of a business rule and can be sidestepped by disabling the trigger temporarily. The same cannot be said for a foreign key constraint. You can't just disable the constraint and turn it back on with bad data like you could with a trigger style implementation.
Well, actually you can do just that:
CREATE TABLE Tab1
(PK int NOT NULL PRIMARY KEY);
CREATE TABLE Tab2
(PK int NOT NULL PRIMARY KEY,
FK int NOT NULL,
CONSTRAINT FK_Tab2 FOREIGN KEY(FK) REFERENCES Tab1(PK));
go
INSERT INTO Tab1 (PK)
VALUES (1);
INSERT INTO Tab2 (PK, FK)
VALUES (1, 1);
-- Error
INSERT INTO Tab2 (PK, FK)
VALUES (2, 2);
go
-- Disable constraint
ALTER TABLE Tab2
NOCHECK CONSTRAINT FK_Tab2;
-- Wrong data is accepted now
INSERT INTO Tab2 (PK, FK)
VALUES (2, 2);
go
-- Reenable constraint
ALTER TABLE Tab2
CHECK CONSTRAINT FK_Tab2;
-- It now works for new data, but existing data is still rubbish
-- First insert is okay; second not.
INSERT INTO Tab2 (PK, FK)
VALUES (3, 1);
INSERT INTO Tab2 (PK, FK)
VALUES (4, 4);
-- Show what's in the table
SELECT * FROM Tab2;
go
-- The only way to find violations after disabling is this weird syntax:
-- (Yes, the double "CHECK" is intended; it's not a typo)
ALTER TABLE Tab2
WITH CHECK CHECK CONSTRAINT FK_Tab2;
go
-- Clean up
DROP TABLE Tab2;
DROP TABLE Tab1;
go
April 6, 2012 at 8:35 am
Hugo Kornelis (4/6/2012)
Sean Lange (4/6/2012)
Basically you can simulate a foreign key via triggers but it is NOT actually a foreign key. In that case it is more of a business rule and can be sidestepped by disabling the trigger temporarily. The same cannot be said for a foreign key constraint. You can't just disable the constraint and turn it back on with bad data like you could with a trigger style implementation.Well, actually you can do just that:
CREATE TABLE Tab1(PK int NOT NULL PRIMARY KEY);
CREATE TABLE Tab2
(PK int NOT NULL PRIMARY KEY,
FK int NOT NULL,
CONSTRAINT FK_Tab2 FOREIGN KEY(FK) REFERENCES Tab1(PK));
go
INSERT INTO Tab1 (PK)
VALUES (1);
INSERT INTO Tab2 (PK, FK)
VALUES (1, 1);
-- Error
INSERT INTO Tab2 (PK, FK)
VALUES (2, 2);
go
-- Disable constraint
ALTER TABLE Tab2
NOCHECK CONSTRAINT FK_Tab2;
-- Wrong data is accepted now
INSERT INTO Tab2 (PK, FK)
VALUES (2, 2);
go
-- Reenable constraint
ALTER TABLE Tab2
CHECK CONSTRAINT FK_Tab2;
-- It now works for new data, but existing data is still rubbish
-- First insert is okay; second not.
INSERT INTO Tab2 (PK, FK)
VALUES (3, 1);
INSERT INTO Tab2 (PK, FK)
VALUES (4, 4);
-- Show what's in the table
SELECT * FROM Tab2;
go
-- The only way to find violations after disabling is this weird syntax:
-- (Yes, the double "CHECK" is intended; it's not a typo)
ALTER TABLE Tab2
WITH CHECK CHECK CONSTRAINT FK_Tab2;
go
-- Clean up
DROP TABLE Tab2;
DROP TABLE Tab1;
go
Hugo I had no idea that would work. I assumed a check constraint would cause issues if you disabled it and put in bad data, then re-enabled it. Thanks for the lesson and excellent example.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 6, 2012 at 8:39 am
Sean Lange (4/6/2012)
Hugo Kornelis (4/6/2012)
Sean Lange (4/6/2012)
Basically you can simulate a foreign key via triggers but it is NOT actually a foreign key. In that case it is more of a business rule and can be sidestepped by disabling the trigger temporarily. The same cannot be said for a foreign key constraint. You can't just disable the constraint and turn it back on with bad data like you could with a trigger style implementation.Well, actually you can do just that:
CREATE TABLE Tab1(PK int NOT NULL PRIMARY KEY);
CREATE TABLE Tab2
(PK int NOT NULL PRIMARY KEY,
FK int NOT NULL,
CONSTRAINT FK_Tab2 FOREIGN KEY(FK) REFERENCES Tab1(PK));
go
INSERT INTO Tab1 (PK)
VALUES (1);
INSERT INTO Tab2 (PK, FK)
VALUES (1, 1);
-- Error
INSERT INTO Tab2 (PK, FK)
VALUES (2, 2);
go
-- Disable constraint
ALTER TABLE Tab2
NOCHECK CONSTRAINT FK_Tab2;
-- Wrong data is accepted now
INSERT INTO Tab2 (PK, FK)
VALUES (2, 2);
go
-- Reenable constraint
ALTER TABLE Tab2
CHECK CONSTRAINT FK_Tab2;
-- It now works for new data, but existing data is still rubbish
-- First insert is okay; second not.
INSERT INTO Tab2 (PK, FK)
VALUES (3, 1);
INSERT INTO Tab2 (PK, FK)
VALUES (4, 4);
-- Show what's in the table
SELECT * FROM Tab2;
go
-- The only way to find violations after disabling is this weird syntax:
-- (Yes, the double "CHECK" is intended; it's not a typo)
ALTER TABLE Tab2
WITH CHECK CHECK CONSTRAINT FK_Tab2;
go
-- Clean up
DROP TABLE Tab2;
DROP TABLE Tab1;
go
Hugo I had no idea that would work. I assumed a check constraint would cause issues if you disabled it and put in bad data, then re-enabled it. Thanks for the lesson and excellent example.
There's actually a bug around this as well, if done within a transaction, https://connect.microsoft.com/SQLServer/feedback/details/685800/parameterized-delete-and-merge-allow-foreign-key-constraint-violations
I was going to post basically what Hugo did, but he beat me to it!
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
Viewing 15 posts - 1 through 15 (of 40 total)
You must be logged in to reply to this topic. Login to reply