[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: To Normalize or Not to Normalize
I try to gauge the impact across the system's users and the architecture you want to get to. Changing the structures, and the refactoring of code that goes along with those changes, opens up the system to subtle failures. Especially if you don't yet fully understand the reasoning behind the existing structures, you may later find that what you thought was a more normalized form was not itself ideal. I'd prioritize those changes based on an understanding of the history of faults that the existing system has, using bug tracking history and anecdotal evidence of problem areas. Then look at the features you want to get to. Put your resources toward the biggest bang for the buck. Leaving fields as-is is a recipe for having to fix something later on, building workarounds to the flaws despite your best efforts to ignore the problem. If you think there is something wrong now, there probably is. What sort of tests exist to verify that the structures and in-use queries actually perform as assumed? Sometimes structures which are left in an apparently schizophrenic state only work because of code that's been hacked to make up for the inconsistencies, leaving latent bugs. Your apparent reluctance to touch the structures suggests a need for unit tests. Names are almost trivial to change, make a little impact on legibility, but expose the users to the greatest risk of not-so-subtle failures. Especially if they've constructed their own systems that depend upon those names. I wouldn't hesitate to rename given other structural changes, or introduction of alternative interfaces/views, but it is dubious on its own. Regards, - Mitch
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|