Foreign key

  • Comments posted to this topic are about the item Foreign key

    Igor Micev,My blog: www.igormicev.com

  • Answer sounds ambigous. Please clarify on the answer explanation.

    M&M

  • 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.

  • 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

  • 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!


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • 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

  • 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

  • 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.

  • 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.

  • 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.

  • 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/

  • 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.

  • 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 Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • 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/

  • 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!

Viewing 15 posts - 1 through 15 (of 40 total)

You must be logged in to reply to this topic. Login to reply