tables inheritance stored procedure
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 CustRegistration
the 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
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.
add a comment |
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 CustRegistration
the 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
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 assumeCustReg
andCustRegistration
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
add a comment |
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 CustRegistration
the 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
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 CustRegistration
the 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
sql-server sql-server-2008-r2
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 assumeCustReg
andCustRegistration
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
add a comment |
I assumeCustReg
andCustRegistration
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
add a comment |
1 Answer
1
active
oldest
votes
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 3 '18 at 1:01
Tomas IngramTomas Ingram
214
214
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
I assume
CustReg
andCustRegistration
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