RE: To Normalize or Not to Normalize
The best aggregate advice so far is to 1. Do the historical homework. 2. Test for performance. 3. Redesign for optimal performance and maintenance if possible. If not, you can wrapper the system and wait until there is time to do so factoring in the costs of conversions. (This is what I think many do.) 4. Fix the names for reuse. You may have an OLAP in your future and business names set by standards are useful here. If you can't do that, document document document. If one can't do the above, evaluate the cost/profit and decide if the task is strategic. Make the schema decisions up front because once in flight, the further you go, the longer the trip back to the airport is. Thanks folks! Michael, some replies inline below. len From: Michael Kay [mailto:mike@s...] >> Here's a fun question that pits theory against experience. >That's your idea of fun? Yes. Education and validation. >> You get a job to create a new generation of an old relational >> database system. Upon reading the as-is schema, you discover >> some amount of denormalization and gnomic names. Do you: >When a system needs significant enhancement, which seems to be the case >here, my preferred strategy is always to make the new system(*) look as much >as possible like the system that I would design if I were starting from >scratch. Mine too but that isn't usually practical for systems where there is a signifcant legacy of data and users. The problem can be that by trying to make a working system match my ideal, I can break it and for reasons that reveal my lack of knowledge or understanding but definitely lose the company money and advantage by crippling the customer. >>(*)or at any rate, those subsystems that need to be changed >Sometimes that's not possible, usually because the system is too fragile to >change or because it's impossible to nail down all its interfaces to other >systems. That situation is no fun at all: the preferred strategy is to find >another project... Cut and run is a strategy. It can mean a change of employer or loss of a customer. Given a system loosely based on standards or on loose standards or specifications, it can mean a whole new business. The other extreme is correct: don't chase bad money. I can't count the number of RFPs we turned down because the complexity, budget and schedule don't sync up, or the times we were compelled to take the work (sales guy wants a commission and yells louder; someone lost a golf bet; someone wants to vacation in that city, etc,) and took a bath. The middle ground is development that favors (say pays for) a strategic set of features. Sanity doesn't always prevail. The extra dimension of complexity is that there may be a third party such as a standards committee specifying yet a third schema which is attractive but conflicts with the ambitions of another party to field a system based on a different schema. Then yeah, it's a good idea to walk away. len
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