
August 10th, 2004, 02:33 PM
|
|
Contributing User
|
|
Join Date: May 2004
Posts: 55
Time spent in forums: 3 h 17 m 53 sec
Reputation Power: 5
|
|
|
I know it isn't exactly good database design, but those fields are part of the results of another query, each containing the sum of a column on another table, generated off of some much more meaningful data. Generally the second total is the one to use, but there are some old legacy entries in the table from before the second total existed, and they need to be accounted for.
I've been working on the system this is part of for a while, and I keep getting requests for additional features to be added to the system, which need to be wedged in via the most efficient route available. This means that some parts of the system are not exactly the most attractive or well designed pieces of code, since they were originally intended to do about half of the things they currently do.
Frankly, if I knew it had to do what it does now (nm what it will do in a week), I would have designed it completely differently from the beginning (Hell, the DB would even be completely in 4th normal form, but needing to arbitrarily pull fields/tables in and out because the people you're coding for change their requirements daily makes it less reasonable to guarantee things stay that way).
In fact, ATM I'm revising some display pages and throwing out a lot of old, very ugly, very kludgy code. Was hoping there was a more elegant way to do that total than to loop through the recordset and add it up as I went, but apparently that's as clean as it can get.
|