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 |
BrianC
Starting Member
4 Posts |
Posted - 2009-08-10 : 06:03:23
|
I am developing an archive database and am currently testing some ideas. As a new developer/programmer I would welcome views on the following:I have two tables from the parent system that hold header information about orders. The first table holds 15 fields about the order as it is raised. The second table holds 11 of those fields along with a further 9 fields relating to the order once it has been processed / despatched.Would it be best to replicate the parent system's tables or would it be better to create a combined table where the final 9 fields are populated using an update script? If the latter, what would be a typical script layout?Cheers,BrianC |
|
RickD
Slow But Sure Yak Herding Master
3608 Posts |
Posted - 2009-08-10 : 06:15:38
|
Sounds like a terribly designed couple of tables to me. Surely the first table should hold the information and the second table just the order number and the extra fields.Personally, if the other 11 fields are the same in both tables and always will be, just store the order number and the extra 9 fields, but you have to guarantee that the other fields will always be the same. |
|
|
ScottWhigham
Starting Member
49 Posts |
Posted - 2009-09-03 : 09:10:37
|
I know this is late to be posting but I'd agree with RickD here along with one caveat: since you are "a new developer", the chance is high that, within 6-18 months, you will see huge flaws in your current design that will, at some point, require fixin'. It is far easier to fix such design issues when you have both tables in the archival database (both the parent and child). If you denormalize/flatten into one single table at the archival database and then later need to make changes to the source database, you'll have a helluva time syncing/changing the archival database. I think that's what RickD was alluding to when he said, "you have to guarantee that the other fields will always be the same".========================================================I have about 1,000 video tutorials on SQL Server 2008, 2005, and 2000 over at http://www.learnitfirst.com/Database-Professionals.aspx |
|
|
|
|
|
|
|