June 10, 2011 at 7:48 am
Hi All
I am looking at redesigning a database that holds transactional data such as Invoices.
The current InvoiceLine table has over 150 columns. We have discussed a few design ideas, one of which is to separate the table out in to multiple tables and apply a 1 to 1 relationship.
For example:
InvoiceLine - hold the main details about the Invoice Line (code, description, quantity, sellprice, tax, etc)
InvoiceLineAdditionalDetail - hold additional information that may or may not be necessary to each line
InvoiceLinePackDetail - additional details about the pack size, pack description (only applicable if the item is sold as part of a multipack etc)
InvoiceLineCostings - for cost differences, standard costs, etc
Is this a feasible design?
Thanks in advance
June 10, 2011 at 7:55 am
You're heading into a database "normalization" discussion. If you're wanting to go down that road (which you should), make sure you do your research and normalize correctly. Understand Normal Forms 1-3 and try to follow those standards when re-designing the database.
Wikipedia is a good start for history and basics.
If you want specific suggestions, you'll need to post your ddl scripts appropriately.
June 10, 2011 at 8:00 am
That's certainly a very normal design for that kind of thing. I've seen variations of it many times.
It creates certain performance and management issues, but so does any other solution for this. Mainly, you'll need to manage your inserts/updates/deletes a little more carefully.
If you're using SQL 2008, take a look at "sparse columns" and "column sets". Those might be good answers for you, since this is the kind of thing they are designed to solve.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 13, 2011 at 6:35 pm
My suggestion for your case is to not split the table into multiple tables unless you have a clear-cut reason to do so, and simply splitting it up because it has a lot of columns is often not a good enough reason. What are normally the reasons people do this? I would say the top 3 reasons typically are:
1. Performance
2. Disk Space
3. Can be difficult to work with, such as when the table is updated throughout lengthy workflow
However, none of these problems will be automatically fixed by making the 1-1 relationships. Performance can suffer because you will force multiple inserts or you will have to always join to query data. Disk space utilization can increase because of adding indexes for the joins or because you create similar indexes accross the tables. And you might make it more difficult to work with, too, but that depends on your particular applications that use this table.
Essentially, you would be implementing a physical model that differs from your logical model.
So ask yourself, do you have a clear-cut reason for making this change?
LinkedIn - http://www.linkedin.com/in/carlosbossy
Blog - http://www.carlosbossy.com
Follow me - @carlosbossy
June 13, 2011 at 6:54 pm
I'm afraid I would disagree with Carlos above, however, my approach is very different for ultra-wides.
For the primary table, make sure it has your business keys and your 90% fields. Those are the fields that are returned in 90% of the queries that would ever need to use this table. IE: A personell table will probably always need first and last name. Favorite pet is not going to be considered often.
Second table is my 'LOB' table. Everything very wide, or rarely used.
Any other tables are sets of columns that would be used in particular scenarios, and bunched together according to that type.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 14, 2011 at 6:13 am
Craig Farrell (6/13/2011)
I'm afraid I would disagree with Carlos above, however, my approach is very different for ultra-wides.For the primary table, make sure it has your business keys and your 90% fields. Those are the fields that are returned in 90% of the queries that would ever need to use this table. IE: A personell table will probably always need first and last name. Favorite pet is not going to be considered often.
Second table is my 'LOB' table. Everything very wide, or rarely used.
Any other tables are sets of columns that would be used in particular scenarios, and bunched together according to that type.
I've used that same approach extensively. Works beautifully. Just make sure the design of the "main data" portion of it works well with 8k pages, and you have something that'll perform like crazy for the majority of your queries.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 14, 2011 at 11:51 am
GSquared (6/14/2011)
Craig Farrell (6/13/2011)
I'm afraid I would disagree with Carlos above, however, my approach is very different for ultra-wides.For the primary table, make sure it has your business keys and your 90% fields. Those are the fields that are returned in 90% of the queries that would ever need to use this table. IE: A personell table will probably always need first and last name. Favorite pet is not going to be considered often.
Second table is my 'LOB' table. Everything very wide, or rarely used.
Any other tables are sets of columns that would be used in particular scenarios, and bunched together according to that type.
I've used that same approach extensively. Works beautifully. Just make sure the design of the "main data" portion of it works well with 8k pages, and you have something that'll perform like crazy for the majority of your queries.
Heh, yeah, I should probably have put a qualifier on that. If I'm getting 3 or less rows per page, I consider it an ultra-wide. A heavily abused table I might double that to 6 or less, just to get the un-necessary stuff out of the way for my 90%'ers.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 17, 2011 at 1:24 pm
craigbroadman (6/10/2011)
I am looking at redesigning a database that holds transactional data such as Invoices.The current InvoiceLine table has over 150 columns. We have discussed a few design ideas, one of which is to separate the table out in to multiple tables and apply a 1 to 1 relationship.
For example:
InvoiceLine - hold the main details about the Invoice Line (code, description, quantity, sellprice, tax, etc)
InvoiceLineAdditionalDetail - hold additional information that may or may not be necessary to each line
InvoiceLinePackDetail - additional details about the pack size, pack description (only applicable if the item is sold as part of a multipack etc)
InvoiceLineCostings - for cost differences, standard costs, etc
Is this a feasible design?
May I ask a couple of questions...
1- Is it fair to say that there is also a InvoiceHeader table with a 1:N relationship with InvoiceLine table?
2- What's the driving reason behind wanting to make InvoiceLine row shorter?
3- What's the average row size of InvoiceLine table? - how many rows per page?
This appears to be an OLTP system, if that's the case it should perform better when following 3NF (at least) data modeling guidelines.
Last but not least, a 1:1 relationship is hard to sell - specially if no compeling reasons are shown.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy