home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.ms-sqlserver      Notorious Rube Goldberg contraption      19,505 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 17,860 of 19,505   
   Erland Sommarskog to wackyphill@yahoo.com   
   Re: How best to handle entity inheritanc   
   29 Jul 10 16:57:08   
   
   4060fc9f   
   From: esquel@sommarskog.se   
      
   wackyphill@yahoo.com (wackyphill@gmail.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, esquel@sommarskog.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/prodinfo/previousversions/books.mspx   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca