Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
chris_wood99
Yak Posting Veteran
70 Posts |
 Posted - 2007-04-24 : 08:05:45
|
| Hi,Im trying to justify to people in a meeting why we have to break down some large financial instrument tables in a new database design we are implementing. They have currently broken the tables down into instruments1 & instruments2, containing approx 300 & 150 columns respectively (further columns will be added!). then they have a view that joins virtually all of these columns. I've asked for the tables to be broken down into more logical groups. they are saying that this will cost more overhead as their views will span more tables. i also complained about the width of the rows, but they claimed that sql 2005will not have a problem as only 1/3 of the row will have any data at one point so will not cause an overhead. can someone give me some definate points on this relating to 2005 as I am fairly new to it.can someone help me with the basic points why they should be split into more logical groups.they are also intending on adding millions of records a year to this table and partioning it will different filegroups. Should you place the indexes for tables on different filegroups as well? |
|
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2007-04-24 : 09:22:42
|
| ouch! I think a lesson in "database modelling 101" looks in order for your people.Particularly the bit about transforming a logical model into an optimal physical model, by taking decisions that may stray away from the pure relational model....like vertical partioning nullable columns into child-table.Nulls do have an overhead, albeit low.....but child records which don't exist have even less overhead. |
 |
|
|
|
|
|
2005 Database basics