tables inheritance stored procedure












0















create table CustomerTypes(
CustomerTypeID int primary key identity(1,1),
CustomerType varchar(11)
);


insert into CustomerTypes(CustomerTypeID,CustomerType
select 1, 'Regular' union all
select 2, 'Business'


create table Customers(
ContactID int primary key identity(1,1),
CustomerTypeID int references CustomerTypes(CustomerTypeID),
FirstName varchar(25)not null,
LastName varchar(25)not null,
DOB date not null,
Telephone varchar(18),
Notes varchar(250),
AddDate date not null
constraint cust_AltPK unique (ContactID,CustomerTypeID)
);


create table Regular_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 1 persisted, --regular
Specification varchar(45),
Date_Joined date,
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create table Business_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 2 persisted, --Business
Business_Name varchar(30)not null,
Business_Type varchar(30),
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create procedure CustReg
@custType varchar(11),
@custTypeID int,
@firtName varchar(25),
@lastName varchar(25),
@dob date,
@telephone varchar(18),
@notes varchar(250),
@addDate date
AS
BEGIN

SET NOCOUNT ON

--SET IDENTITY_INSERT CustomerTypes ON

INSERT INTO CustomerTypes values(@custType)
SELECT 1,'Regular'union all
select 2, 'Business'

--SET @CustTypeID = SCOPE_IDENTITY()
--SET IDENTITY_INSERT CustomerTypes OFF

DECLARE @ContactID int

INSERT INTO
Customers(CustomerTypeID,FirstName,LastName,DOB,Telephone,Notes,AddDate)
VALUES(@CustTypeID,@firtName,@lastName,@dob,@telephone,@notes,@addDate)

SET @ContactID = SCOPE_IDENTITY()
end


exec CustRegistration 'Business','5','Jean','Bruno','2012-03-09','073098743','business trip','2017-07-04'


After running exec CustRegistrationthe Customer table is populated with 5 in CustomerTypeID column. I was excepting to get a warning message of foreign key conflict in table customerType. What am I doing wrong?










share|improve this question
















bumped to the homepage by Community 9 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
















  • I assume CustReg and CustRegistration are the same thing and you haven't actually copied a totally different procedure into your question?

    – Mark Sinkinson
    Mar 2 '18 at 10:53











  • custReg and custRegistration are the same. My point is CustomerTypeID in customer table is a reference of CustomerType table.i want the exec CustReg to accept only option 1-'Regular' or 2-'Business' as input in CustomerTypeID

    – juclart ngouedi
    Mar 2 '18 at 12:21
















0















create table CustomerTypes(
CustomerTypeID int primary key identity(1,1),
CustomerType varchar(11)
);


insert into CustomerTypes(CustomerTypeID,CustomerType
select 1, 'Regular' union all
select 2, 'Business'


create table Customers(
ContactID int primary key identity(1,1),
CustomerTypeID int references CustomerTypes(CustomerTypeID),
FirstName varchar(25)not null,
LastName varchar(25)not null,
DOB date not null,
Telephone varchar(18),
Notes varchar(250),
AddDate date not null
constraint cust_AltPK unique (ContactID,CustomerTypeID)
);


create table Regular_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 1 persisted, --regular
Specification varchar(45),
Date_Joined date,
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create table Business_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 2 persisted, --Business
Business_Name varchar(30)not null,
Business_Type varchar(30),
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create procedure CustReg
@custType varchar(11),
@custTypeID int,
@firtName varchar(25),
@lastName varchar(25),
@dob date,
@telephone varchar(18),
@notes varchar(250),
@addDate date
AS
BEGIN

SET NOCOUNT ON

--SET IDENTITY_INSERT CustomerTypes ON

INSERT INTO CustomerTypes values(@custType)
SELECT 1,'Regular'union all
select 2, 'Business'

--SET @CustTypeID = SCOPE_IDENTITY()
--SET IDENTITY_INSERT CustomerTypes OFF

DECLARE @ContactID int

INSERT INTO
Customers(CustomerTypeID,FirstName,LastName,DOB,Telephone,Notes,AddDate)
VALUES(@CustTypeID,@firtName,@lastName,@dob,@telephone,@notes,@addDate)

SET @ContactID = SCOPE_IDENTITY()
end


exec CustRegistration 'Business','5','Jean','Bruno','2012-03-09','073098743','business trip','2017-07-04'


After running exec CustRegistrationthe Customer table is populated with 5 in CustomerTypeID column. I was excepting to get a warning message of foreign key conflict in table customerType. What am I doing wrong?










share|improve this question
















bumped to the homepage by Community 9 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
















  • I assume CustReg and CustRegistration are the same thing and you haven't actually copied a totally different procedure into your question?

    – Mark Sinkinson
    Mar 2 '18 at 10:53











  • custReg and custRegistration are the same. My point is CustomerTypeID in customer table is a reference of CustomerType table.i want the exec CustReg to accept only option 1-'Regular' or 2-'Business' as input in CustomerTypeID

    – juclart ngouedi
    Mar 2 '18 at 12:21














0












0








0








create table CustomerTypes(
CustomerTypeID int primary key identity(1,1),
CustomerType varchar(11)
);


insert into CustomerTypes(CustomerTypeID,CustomerType
select 1, 'Regular' union all
select 2, 'Business'


create table Customers(
ContactID int primary key identity(1,1),
CustomerTypeID int references CustomerTypes(CustomerTypeID),
FirstName varchar(25)not null,
LastName varchar(25)not null,
DOB date not null,
Telephone varchar(18),
Notes varchar(250),
AddDate date not null
constraint cust_AltPK unique (ContactID,CustomerTypeID)
);


create table Regular_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 1 persisted, --regular
Specification varchar(45),
Date_Joined date,
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create table Business_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 2 persisted, --Business
Business_Name varchar(30)not null,
Business_Type varchar(30),
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create procedure CustReg
@custType varchar(11),
@custTypeID int,
@firtName varchar(25),
@lastName varchar(25),
@dob date,
@telephone varchar(18),
@notes varchar(250),
@addDate date
AS
BEGIN

SET NOCOUNT ON

--SET IDENTITY_INSERT CustomerTypes ON

INSERT INTO CustomerTypes values(@custType)
SELECT 1,'Regular'union all
select 2, 'Business'

--SET @CustTypeID = SCOPE_IDENTITY()
--SET IDENTITY_INSERT CustomerTypes OFF

DECLARE @ContactID int

INSERT INTO
Customers(CustomerTypeID,FirstName,LastName,DOB,Telephone,Notes,AddDate)
VALUES(@CustTypeID,@firtName,@lastName,@dob,@telephone,@notes,@addDate)

SET @ContactID = SCOPE_IDENTITY()
end


exec CustRegistration 'Business','5','Jean','Bruno','2012-03-09','073098743','business trip','2017-07-04'


After running exec CustRegistrationthe Customer table is populated with 5 in CustomerTypeID column. I was excepting to get a warning message of foreign key conflict in table customerType. What am I doing wrong?










share|improve this question
















create table CustomerTypes(
CustomerTypeID int primary key identity(1,1),
CustomerType varchar(11)
);


insert into CustomerTypes(CustomerTypeID,CustomerType
select 1, 'Regular' union all
select 2, 'Business'


create table Customers(
ContactID int primary key identity(1,1),
CustomerTypeID int references CustomerTypes(CustomerTypeID),
FirstName varchar(25)not null,
LastName varchar(25)not null,
DOB date not null,
Telephone varchar(18),
Notes varchar(250),
AddDate date not null
constraint cust_AltPK unique (ContactID,CustomerTypeID)
);


create table Regular_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 1 persisted, --regular
Specification varchar(45),
Date_Joined date,
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create table Business_Customer(
ContactID int primary key identity(1,1),
CustomerTypeID as 2 persisted, --Business
Business_Name varchar(30)not null,
Business_Type varchar(30),
foreign key (ContactID,CustomerTypeID) references Customers(ContactID,CustomerTypeID)
);

create procedure CustReg
@custType varchar(11),
@custTypeID int,
@firtName varchar(25),
@lastName varchar(25),
@dob date,
@telephone varchar(18),
@notes varchar(250),
@addDate date
AS
BEGIN

SET NOCOUNT ON

--SET IDENTITY_INSERT CustomerTypes ON

INSERT INTO CustomerTypes values(@custType)
SELECT 1,'Regular'union all
select 2, 'Business'

--SET @CustTypeID = SCOPE_IDENTITY()
--SET IDENTITY_INSERT CustomerTypes OFF

DECLARE @ContactID int

INSERT INTO
Customers(CustomerTypeID,FirstName,LastName,DOB,Telephone,Notes,AddDate)
VALUES(@CustTypeID,@firtName,@lastName,@dob,@telephone,@notes,@addDate)

SET @ContactID = SCOPE_IDENTITY()
end


exec CustRegistration 'Business','5','Jean','Bruno','2012-03-09','073098743','business trip','2017-07-04'


After running exec CustRegistrationthe Customer table is populated with 5 in CustomerTypeID column. I was excepting to get a warning message of foreign key conflict in table customerType. What am I doing wrong?







sql-server sql-server-2008-r2






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 2 '18 at 10:52









Mark Sinkinson

7,81432947




7,81432947










asked Mar 2 '18 at 9:35









juclart ngouedijuclart ngouedi

13




13





bumped to the homepage by Community 9 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community 9 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • I assume CustReg and CustRegistration are the same thing and you haven't actually copied a totally different procedure into your question?

    – Mark Sinkinson
    Mar 2 '18 at 10:53











  • custReg and custRegistration are the same. My point is CustomerTypeID in customer table is a reference of CustomerType table.i want the exec CustReg to accept only option 1-'Regular' or 2-'Business' as input in CustomerTypeID

    – juclart ngouedi
    Mar 2 '18 at 12:21



















  • I assume CustReg and CustRegistration are the same thing and you haven't actually copied a totally different procedure into your question?

    – Mark Sinkinson
    Mar 2 '18 at 10:53











  • custReg and custRegistration are the same. My point is CustomerTypeID in customer table is a reference of CustomerType table.i want the exec CustReg to accept only option 1-'Regular' or 2-'Business' as input in CustomerTypeID

    – juclart ngouedi
    Mar 2 '18 at 12:21

















I assume CustReg and CustRegistration are the same thing and you haven't actually copied a totally different procedure into your question?

– Mark Sinkinson
Mar 2 '18 at 10:53





I assume CustReg and CustRegistration are the same thing and you haven't actually copied a totally different procedure into your question?

– Mark Sinkinson
Mar 2 '18 at 10:53













custReg and custRegistration are the same. My point is CustomerTypeID in customer table is a reference of CustomerType table.i want the exec CustReg to accept only option 1-'Regular' or 2-'Business' as input in CustomerTypeID

– juclart ngouedi
Mar 2 '18 at 12:21





custReg and custRegistration are the same. My point is CustomerTypeID in customer table is a reference of CustomerType table.i want the exec CustReg to accept only option 1-'Regular' or 2-'Business' as input in CustomerTypeID

– juclart ngouedi
Mar 2 '18 at 12:21










1 Answer
1






active

oldest

votes


















0














It looks possible that you have inserted more into the customer type table than you think via the CustReg proc as CustomerType is not unique and the proc does



INSERT INTO CustomerTypes values(@custType)
....


If I'm honest the model could do with some work as the alternate key of the customer table appears to contradict the primary key.



At the moment customer 1 and 2 could be the same customer of different types. That may sound like it makes sense but I'd suggest it is incorrect and allows for a many to one relationship between parent and child despite trying to enforce the type. In general super types should in general be unaware of subtypes.



As your question is around inheritance then it would follow that



A business customer is A customer



A regular customer is A customer



A customer is either A regular customer or A business customer or potentially both.



I'd remove the customer type table/enumeration and the calculated customer type columns and just use a Customer table and the two child tables.



The primary key of the child tables should be the 'inherited' customer ID i.e. the parent table should have a one to one relationship with any child table.



Use the fact that the customer ID exists or is in the child table to determine what type or types of customer they are.



If you must enforce that the customer can only be of one subtype this could potentially be done via an indexed view as a union of the customer ids in the child tables. That's a theory and not something I've tried.



Unrelated but notes about a customer would probably be better served as a separate table also.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    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',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    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%2fdba.stackexchange.com%2fquestions%2f199198%2ftables-inheritance-stored-procedure%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    It looks possible that you have inserted more into the customer type table than you think via the CustReg proc as CustomerType is not unique and the proc does



    INSERT INTO CustomerTypes values(@custType)
    ....


    If I'm honest the model could do with some work as the alternate key of the customer table appears to contradict the primary key.



    At the moment customer 1 and 2 could be the same customer of different types. That may sound like it makes sense but I'd suggest it is incorrect and allows for a many to one relationship between parent and child despite trying to enforce the type. In general super types should in general be unaware of subtypes.



    As your question is around inheritance then it would follow that



    A business customer is A customer



    A regular customer is A customer



    A customer is either A regular customer or A business customer or potentially both.



    I'd remove the customer type table/enumeration and the calculated customer type columns and just use a Customer table and the two child tables.



    The primary key of the child tables should be the 'inherited' customer ID i.e. the parent table should have a one to one relationship with any child table.



    Use the fact that the customer ID exists or is in the child table to determine what type or types of customer they are.



    If you must enforce that the customer can only be of one subtype this could potentially be done via an indexed view as a union of the customer ids in the child tables. That's a theory and not something I've tried.



    Unrelated but notes about a customer would probably be better served as a separate table also.






    share|improve this answer




























      0














      It looks possible that you have inserted more into the customer type table than you think via the CustReg proc as CustomerType is not unique and the proc does



      INSERT INTO CustomerTypes values(@custType)
      ....


      If I'm honest the model could do with some work as the alternate key of the customer table appears to contradict the primary key.



      At the moment customer 1 and 2 could be the same customer of different types. That may sound like it makes sense but I'd suggest it is incorrect and allows for a many to one relationship between parent and child despite trying to enforce the type. In general super types should in general be unaware of subtypes.



      As your question is around inheritance then it would follow that



      A business customer is A customer



      A regular customer is A customer



      A customer is either A regular customer or A business customer or potentially both.



      I'd remove the customer type table/enumeration and the calculated customer type columns and just use a Customer table and the two child tables.



      The primary key of the child tables should be the 'inherited' customer ID i.e. the parent table should have a one to one relationship with any child table.



      Use the fact that the customer ID exists or is in the child table to determine what type or types of customer they are.



      If you must enforce that the customer can only be of one subtype this could potentially be done via an indexed view as a union of the customer ids in the child tables. That's a theory and not something I've tried.



      Unrelated but notes about a customer would probably be better served as a separate table also.






      share|improve this answer


























        0












        0








        0







        It looks possible that you have inserted more into the customer type table than you think via the CustReg proc as CustomerType is not unique and the proc does



        INSERT INTO CustomerTypes values(@custType)
        ....


        If I'm honest the model could do with some work as the alternate key of the customer table appears to contradict the primary key.



        At the moment customer 1 and 2 could be the same customer of different types. That may sound like it makes sense but I'd suggest it is incorrect and allows for a many to one relationship between parent and child despite trying to enforce the type. In general super types should in general be unaware of subtypes.



        As your question is around inheritance then it would follow that



        A business customer is A customer



        A regular customer is A customer



        A customer is either A regular customer or A business customer or potentially both.



        I'd remove the customer type table/enumeration and the calculated customer type columns and just use a Customer table and the two child tables.



        The primary key of the child tables should be the 'inherited' customer ID i.e. the parent table should have a one to one relationship with any child table.



        Use the fact that the customer ID exists or is in the child table to determine what type or types of customer they are.



        If you must enforce that the customer can only be of one subtype this could potentially be done via an indexed view as a union of the customer ids in the child tables. That's a theory and not something I've tried.



        Unrelated but notes about a customer would probably be better served as a separate table also.






        share|improve this answer













        It looks possible that you have inserted more into the customer type table than you think via the CustReg proc as CustomerType is not unique and the proc does



        INSERT INTO CustomerTypes values(@custType)
        ....


        If I'm honest the model could do with some work as the alternate key of the customer table appears to contradict the primary key.



        At the moment customer 1 and 2 could be the same customer of different types. That may sound like it makes sense but I'd suggest it is incorrect and allows for a many to one relationship between parent and child despite trying to enforce the type. In general super types should in general be unaware of subtypes.



        As your question is around inheritance then it would follow that



        A business customer is A customer



        A regular customer is A customer



        A customer is either A regular customer or A business customer or potentially both.



        I'd remove the customer type table/enumeration and the calculated customer type columns and just use a Customer table and the two child tables.



        The primary key of the child tables should be the 'inherited' customer ID i.e. the parent table should have a one to one relationship with any child table.



        Use the fact that the customer ID exists or is in the child table to determine what type or types of customer they are.



        If you must enforce that the customer can only be of one subtype this could potentially be done via an indexed view as a union of the customer ids in the child tables. That's a theory and not something I've tried.



        Unrelated but notes about a customer would probably be better served as a separate table also.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 3 '18 at 1:01









        Tomas IngramTomas Ingram

        214




        214






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f199198%2ftables-inheritance-stored-procedure%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

            Liste der Baudenkmale in Friedland (Mecklenburg)

            Single-Malt-Whisky

            Czorneboh