Can't create foreign key using individual columns against multiple-column primary key











up vote
0
down vote

favorite












I can not find out what is wrong that i am getting the error message:




Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
keys in the referenced table 'Airplane_type' that match the
referencing column list in the foreign key
'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
Could not create constraint. See previous errors.




Here is that section of the query:



CREATE TABLE Airplane_type
(
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
PRIMARY KEY(make, model)
);

CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
);


Any help is greatly appreciated, thanks










share|improve this question




























    up vote
    0
    down vote

    favorite












    I can not find out what is wrong that i am getting the error message:




    Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
    keys in the referenced table 'Airplane_type' that match the
    referencing column list in the foreign key
    'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
    Could not create constraint. See previous errors.




    Here is that section of the query:



    CREATE TABLE Airplane_type
    (
    make VARCHAR NOT NULL,
    model VARCHAR NOT NULL,
    type VARCHAR NOT NULL,
    business_capacity INT NOT NULL,
    economy_capacity INT NOT NULL,
    range INT NOT NULL,
    weight INT NOT NULL,
    length INT NOT NULL,
    wingspan INT NOT NULL,
    PRIMARY KEY(make, model)
    );

    CREATE TABLE Airplane
    (
    airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
    make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
    model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
    );


    Any help is greatly appreciated, thanks










    share|improve this question


























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I can not find out what is wrong that i am getting the error message:




      Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
      keys in the referenced table 'Airplane_type' that match the
      referencing column list in the foreign key
      'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
      Could not create constraint. See previous errors.




      Here is that section of the query:



      CREATE TABLE Airplane_type
      (
      make VARCHAR NOT NULL,
      model VARCHAR NOT NULL,
      type VARCHAR NOT NULL,
      business_capacity INT NOT NULL,
      economy_capacity INT NOT NULL,
      range INT NOT NULL,
      weight INT NOT NULL,
      length INT NOT NULL,
      wingspan INT NOT NULL,
      PRIMARY KEY(make, model)
      );

      CREATE TABLE Airplane
      (
      airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
      make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
      model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
      );


      Any help is greatly appreciated, thanks










      share|improve this question















      I can not find out what is wrong that i am getting the error message:




      Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
      keys in the referenced table 'Airplane_type' that match the
      referencing column list in the foreign key
      'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
      Could not create constraint. See previous errors.




      Here is that section of the query:



      CREATE TABLE Airplane_type
      (
      make VARCHAR NOT NULL,
      model VARCHAR NOT NULL,
      type VARCHAR NOT NULL,
      business_capacity INT NOT NULL,
      economy_capacity INT NOT NULL,
      range INT NOT NULL,
      weight INT NOT NULL,
      length INT NOT NULL,
      wingspan INT NOT NULL,
      PRIMARY KEY(make, model)
      );

      CREATE TABLE Airplane
      (
      airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
      make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
      model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
      );


      Any help is greatly appreciated, thanks







      sql-server-2008 constraints






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 16 '12 at 21:50









      Aaron Bertrand

      205k27357401




      205k27357401










      asked Apr 16 '12 at 21:46









      Troy Loberger

      168422




      168422
























          3 Answers
          3






          active

          oldest

          votes

















          up vote
          3
          down vote



          accepted










          You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.



          CREATE TABLE Airplane
          (
          airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
          make VARCHAR NOT NULL,
          model VARCHAR NOT NULL,
          CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
          REFERENCES Airplane_type(make, model)
          );


          Also, why are you using VARCHAR without specifying a length? Please read this blog post:




          • Bad habits to kick : declaring VARCHAR without (length)






          share|improve this answer























          • Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
            – Tony Hopkinson
            Apr 16 '12 at 22:00










          • Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
            – Tony Hopkinson
            Apr 16 '12 at 22:03


















          up vote
          1
          down vote













          The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.






          share|improve this answer




























            up vote
            0
            down vote













            CREATE TABLE Airplane_type
            (
            airplane_type_id not null Identity(1,1),
            make VARCHAR NOT NULL,
            model VARCHAR NOT NULL,
            type VARCHAR NOT NULL,
            business_capacity INT NOT NULL,
            economy_capacity INT NOT NULL,
            range INT NOT NULL,
            weight INT NOT NULL,
            length INT NOT NULL,
            wingspan INT NOT NULL,
            CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
            Constraint UK_Spotted_By_AARON Unique Key (make, model)
            );

            CREATE TABLE Airplane
            (
            airplane_ID VARCHAR(3) NOT NULL,
            airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
            Foreign Key References(AirPlane.Airplane_type_id),
            Constraint PK_Airplane Primary Key (Airplane_id),
            );


            Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.






            share|improve this answer























            • How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
              – Aaron Bertrand
              Apr 16 '12 at 21:59












            • I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
              – Tony Hopkinson
              Apr 16 '12 at 22:09










            • No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
              – Aaron Bertrand
              Apr 16 '12 at 22:15












            • Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
              – Aaron Bertrand
              Apr 16 '12 at 22:18










            • Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
              – Tony Hopkinson
              Apr 16 '12 at 22:21











            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














             

            draft saved


            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f10182170%2fcant-create-foreign-key-using-individual-columns-against-multiple-column-primar%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            3
            down vote



            accepted










            You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.



            CREATE TABLE Airplane
            (
            airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
            make VARCHAR NOT NULL,
            model VARCHAR NOT NULL,
            CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
            REFERENCES Airplane_type(make, model)
            );


            Also, why are you using VARCHAR without specifying a length? Please read this blog post:




            • Bad habits to kick : declaring VARCHAR without (length)






            share|improve this answer























            • Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
              – Tony Hopkinson
              Apr 16 '12 at 22:00










            • Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
              – Tony Hopkinson
              Apr 16 '12 at 22:03















            up vote
            3
            down vote



            accepted










            You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.



            CREATE TABLE Airplane
            (
            airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
            make VARCHAR NOT NULL,
            model VARCHAR NOT NULL,
            CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
            REFERENCES Airplane_type(make, model)
            );


            Also, why are you using VARCHAR without specifying a length? Please read this blog post:




            • Bad habits to kick : declaring VARCHAR without (length)






            share|improve this answer























            • Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
              – Tony Hopkinson
              Apr 16 '12 at 22:00










            • Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
              – Tony Hopkinson
              Apr 16 '12 at 22:03













            up vote
            3
            down vote



            accepted







            up vote
            3
            down vote



            accepted






            You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.



            CREATE TABLE Airplane
            (
            airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
            make VARCHAR NOT NULL,
            model VARCHAR NOT NULL,
            CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
            REFERENCES Airplane_type(make, model)
            );


            Also, why are you using VARCHAR without specifying a length? Please read this blog post:




            • Bad habits to kick : declaring VARCHAR without (length)






            share|improve this answer














            You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.



            CREATE TABLE Airplane
            (
            airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
            make VARCHAR NOT NULL,
            model VARCHAR NOT NULL,
            CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
            REFERENCES Airplane_type(make, model)
            );


            Also, why are you using VARCHAR without specifying a length? Please read this blog post:




            • Bad habits to kick : declaring VARCHAR without (length)







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 10 at 21:31

























            answered Apr 16 '12 at 21:49









            Aaron Bertrand

            205k27357401




            205k27357401












            • Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
              – Tony Hopkinson
              Apr 16 '12 at 22:00










            • Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
              – Tony Hopkinson
              Apr 16 '12 at 22:03


















            • Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
              – Tony Hopkinson
              Apr 16 '12 at 22:00










            • Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
              – Tony Hopkinson
              Apr 16 '12 at 22:03
















            Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
            – Tony Hopkinson
            Apr 16 '12 at 22:00




            Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
            – Tony Hopkinson
            Apr 16 '12 at 22:00












            Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
            – Tony Hopkinson
            Apr 16 '12 at 22:03




            Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
            – Tony Hopkinson
            Apr 16 '12 at 22:03












            up vote
            1
            down vote













            The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.






            share|improve this answer

























              up vote
              1
              down vote













              The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.






              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.






                share|improve this answer












                The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 16 '12 at 21:50









                Joe Stefanelli

                109k13189203




                109k13189203






















                    up vote
                    0
                    down vote













                    CREATE TABLE Airplane_type
                    (
                    airplane_type_id not null Identity(1,1),
                    make VARCHAR NOT NULL,
                    model VARCHAR NOT NULL,
                    type VARCHAR NOT NULL,
                    business_capacity INT NOT NULL,
                    economy_capacity INT NOT NULL,
                    range INT NOT NULL,
                    weight INT NOT NULL,
                    length INT NOT NULL,
                    wingspan INT NOT NULL,
                    CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
                    Constraint UK_Spotted_By_AARON Unique Key (make, model)
                    );

                    CREATE TABLE Airplane
                    (
                    airplane_ID VARCHAR(3) NOT NULL,
                    airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
                    Foreign Key References(AirPlane.Airplane_type_id),
                    Constraint PK_Airplane Primary Key (Airplane_id),
                    );


                    Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.






                    share|improve this answer























                    • How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
                      – Aaron Bertrand
                      Apr 16 '12 at 21:59












                    • I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
                      – Tony Hopkinson
                      Apr 16 '12 at 22:09










                    • No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:15












                    • Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:18










                    • Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
                      – Tony Hopkinson
                      Apr 16 '12 at 22:21















                    up vote
                    0
                    down vote













                    CREATE TABLE Airplane_type
                    (
                    airplane_type_id not null Identity(1,1),
                    make VARCHAR NOT NULL,
                    model VARCHAR NOT NULL,
                    type VARCHAR NOT NULL,
                    business_capacity INT NOT NULL,
                    economy_capacity INT NOT NULL,
                    range INT NOT NULL,
                    weight INT NOT NULL,
                    length INT NOT NULL,
                    wingspan INT NOT NULL,
                    CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
                    Constraint UK_Spotted_By_AARON Unique Key (make, model)
                    );

                    CREATE TABLE Airplane
                    (
                    airplane_ID VARCHAR(3) NOT NULL,
                    airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
                    Foreign Key References(AirPlane.Airplane_type_id),
                    Constraint PK_Airplane Primary Key (Airplane_id),
                    );


                    Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.






                    share|improve this answer























                    • How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
                      – Aaron Bertrand
                      Apr 16 '12 at 21:59












                    • I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
                      – Tony Hopkinson
                      Apr 16 '12 at 22:09










                    • No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:15












                    • Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:18










                    • Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
                      – Tony Hopkinson
                      Apr 16 '12 at 22:21













                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    CREATE TABLE Airplane_type
                    (
                    airplane_type_id not null Identity(1,1),
                    make VARCHAR NOT NULL,
                    model VARCHAR NOT NULL,
                    type VARCHAR NOT NULL,
                    business_capacity INT NOT NULL,
                    economy_capacity INT NOT NULL,
                    range INT NOT NULL,
                    weight INT NOT NULL,
                    length INT NOT NULL,
                    wingspan INT NOT NULL,
                    CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
                    Constraint UK_Spotted_By_AARON Unique Key (make, model)
                    );

                    CREATE TABLE Airplane
                    (
                    airplane_ID VARCHAR(3) NOT NULL,
                    airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
                    Foreign Key References(AirPlane.Airplane_type_id),
                    Constraint PK_Airplane Primary Key (Airplane_id),
                    );


                    Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.






                    share|improve this answer














                    CREATE TABLE Airplane_type
                    (
                    airplane_type_id not null Identity(1,1),
                    make VARCHAR NOT NULL,
                    model VARCHAR NOT NULL,
                    type VARCHAR NOT NULL,
                    business_capacity INT NOT NULL,
                    economy_capacity INT NOT NULL,
                    range INT NOT NULL,
                    weight INT NOT NULL,
                    length INT NOT NULL,
                    wingspan INT NOT NULL,
                    CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
                    Constraint UK_Spotted_By_AARON Unique Key (make, model)
                    );

                    CREATE TABLE Airplane
                    (
                    airplane_ID VARCHAR(3) NOT NULL,
                    airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
                    Foreign Key References(AirPlane.Airplane_type_id),
                    Constraint PK_Airplane Primary Key (Airplane_id),
                    );


                    Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Apr 16 '12 at 22:24

























                    answered Apr 16 '12 at 21:58









                    Tony Hopkinson

                    18.6k32437




                    18.6k32437












                    • How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
                      – Aaron Bertrand
                      Apr 16 '12 at 21:59












                    • I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
                      – Tony Hopkinson
                      Apr 16 '12 at 22:09










                    • No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:15












                    • Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:18










                    • Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
                      – Tony Hopkinson
                      Apr 16 '12 at 22:21


















                    • How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
                      – Aaron Bertrand
                      Apr 16 '12 at 21:59












                    • I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
                      – Tony Hopkinson
                      Apr 16 '12 at 22:09










                    • No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:15












                    • Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
                      – Aaron Bertrand
                      Apr 16 '12 at 22:18










                    • Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
                      – Tony Hopkinson
                      Apr 16 '12 at 22:21
















                    How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
                    – Aaron Bertrand
                    Apr 16 '12 at 21:59






                    How does adding an identity column and removing the key on make,model help anything? Now you can have duplicate make,model because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
                    – Aaron Bertrand
                    Apr 16 '12 at 21:59














                    I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
                    – Tony Hopkinson
                    Apr 16 '12 at 22:09




                    I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
                    – Tony Hopkinson
                    Apr 16 '12 at 22:09












                    No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
                    – Aaron Bertrand
                    Apr 16 '12 at 22:15






                    No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
                    – Aaron Bertrand
                    Apr 16 '12 at 22:15














                    Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
                    – Aaron Bertrand
                    Apr 16 '12 at 22:18




                    Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
                    – Aaron Bertrand
                    Apr 16 '12 at 22:18












                    Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
                    – Tony Hopkinson
                    Apr 16 '12 at 22:21




                    Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
                    – Tony Hopkinson
                    Apr 16 '12 at 22:21


















                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f10182170%2fcant-create-foreign-key-using-individual-columns-against-multiple-column-primar%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Bressuire

                    Vorschmack

                    Quarantine