dbTalk Databases Forums  

How best to handle entity inheritance?

comp.databases.ms-sqlserver comp.databases.ms-sqlserver


Discuss How best to handle entity inheritance? in the comp.databases.ms-sqlserver forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
wackyphill@yahoo.com
 
Posts: n/a

Default How best to handle entity inheritance? - 07-29-2010 , 07:26 AM






I have a table that holds agreement information. It works well for 95%
of the agreements we record.

But there is a certain type of agreement that would require another 6
or so fields to capture info specific to that type of agreement.

My question is if its better to just add those 6 fields to the
existing agreement table knowing that the info is meaningless to many
of the agreement records or if its better to create another table w/ a
1:1 relationship w/ the original agreement table to extend it in the
case of these special types of agreements.

Neither option is all that attractive to me, but I wanted to know if
one was considered a better practice than the other when you have a
choice.

Thanks for any help.

Reply With Quote
  #2  
Old   
Erland Sommarskog
 
Posts: n/a

Default Re: How best to handle entity inheritance? - 07-29-2010 , 09:57 AM






wackyphill (AT) yahoo (DOT) com (wackyphill (AT) gmail (DOT) com) writes:
Quote:
I have a table that holds agreement information. It works well for 95%
of the agreements we record.

But there is a certain type of agreement that would require another 6
or so fields to capture info specific to that type of agreement.

My question is if its better to just add those 6 fields to the
existing agreement table knowing that the info is meaningless to many
of the agreement records or if its better to create another table w/ a
1:1 relationship w/ the original agreement table to extend it in the
case of these special types of agreements.

Neither option is all that attractive to me, but I wanted to know if
one was considered a better practice than the other when you have a
choice.
It's certainly a trade-off situation.

In the system I work with there is a table that holds contract notes.
Contract notes for bonds and other interest-related instruments requires
six extra columns which are meaningless for stocks. As in your case, the
bonds is just some 3-5% of this big table. Originally, the bond-specific
columns were in the table itself, but in order to preserve some space,
I decided at one point to put them in a table of its own. Which meant
many queries had to be rewritten and include an extra left join.

When I did this, the current SQL Server versions were SQL 2000 with SQL 2005
on the way in.

Now, in SQL 2008 there exists a different solution: I could mark these
columns as SPARSE, and these columns would not take up any space when they
are NULL. (The columns in questions are float and datetime values, so
unless SPARSE is used, they take up 8 bytes, NULL or NOT.)

I should add that there is a second advantage with using an extra table. If
there are constraints appliable to these columns, for instance if it is an
agreement of type X the columns A, B, and C must be NOT NULL, then this is a
lot easier to handle it there is a separate table. And in the same vein, if
it is a separate table, you can easier prevent that there suddenly is data
in these columns for other type of agreements.


--
Erland Sommarskog, SQL Server MVP, esquel (AT) sommarskog (DOT) se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

Reply With Quote
  #3  
Old   
wackyphill@yahoo.com
 
Posts: n/a

Default Re: How best to handle entity inheritance? - 08-05-2010 , 10:51 AM



On Jul 29, 10:57*am, Erland Sommarskog <esq... (AT) sommarskog (DOT) se> wrote:
Quote:
wackyph... (AT) yahoo (DOT) com (wackyph... (AT) gmail (DOT) com) writes:
I have a table that holds agreement information. It works well for 95%
of the agreements we record.

But there is a certain type of agreement that would require another 6
or so fields to capture info specific to that type of agreement.

My question is if its better to just add those 6 fields to the
existing agreement table knowing that the info is meaningless to many
of the agreement records or if its better to create another table w/ a
1:1 relationship w/ the original agreement table to extend it in the
case of these special types of agreements.

Neither option is all that attractive to me, but I wanted to know if
one was considered a better practice than the other when you have a
choice.

It's certainly a trade-off situation.

In the system I work with there is a table that holds contract notes.
Contract notes for bonds and other interest-related instruments requires
six extra columns which are meaningless for stocks. As in your case, the
bonds is just some 3-5% of this big table. Originally, the bond-specific
columns were in the table itself, but in order to preserve some space,
I decided at one point to put them in a table of its own. Which meant
many queries had to be rewritten and include an extra left join.

When I did this, the current SQL Server versions were SQL 2000 with SQL 2005
on the way in.

Now, in SQL 2008 there exists a different solution: I could mark these
columns as SPARSE, and these columns would not take up any space when they
are NULL. (The columns in questions are float and datetime values, so
unless SPARSE is used, they take up 8 bytes, NULL or NOT.)

I should add that there is a second advantage with using an extra table. If
there are constraints appliable to these columns, for instance if it is an
agreement of type X the columns A, B, and C must be NOT NULL, then this is a
lot easier to handle it there is a separate table. And in the same vein, if
it is a separate table, you can easier prevent that there suddenly is data
in these columns for other type of agreements.

--
Erland Sommarskog, SQL Server MVP, esq... (AT) sommarskog (DOT) se

Links for SQL Server Books Online:
SQL 2008:http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005:http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000:http://www.microsoft.com/sql/prodinf...ns/books.mspx- Hide quoted text -

- Show quoted text -
Thanks for the input as always Erland.

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.