[
Lists Home |
Date Index |
Thread Index
]
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@saxonica.com]
>> 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
|
