If you went to a company and saw that their programming applications
were pulling data from un-normalized tables, how would you transition
them to normalized tables and yet keep the application running
smoothly?

metaperl wrote:
First of all, decide if it's worth it to do this. Sometimes the
information systems have a limited lifespan, and it's not worth the
effort to redesign it, if the whole system will be replaced a few months
later. Or if the company goes under.

But here's one possible plan:

1. Rename the current tables to something else.
2. Create updatable views to those tables, in a simple one view to one
table fashion.
3. Gradually restructure the underlying tables to be normalized, as you
redefine the views' query to re-form the non-normalized representation.

This way minimizes rewriting code in the applications using these tables.

But it depends on having a good implementation of views, that permits
using triggers or something, to make views on complex queries into
updatable views (which eliminates MySQL, because they have no solution
to make such views updatable).

Or else you need to rewrite the INSERT/UPDATE/DELETE queries to write to
the underlying tables, even if you continue to use the SELECT queries
without alteration.

Regards,
Bill K.

metaperl wrote:
converting legacy applications can be tricky.

One way to deal with this is the rip it all out approach. So if your
project is to replace the legacy system, you have free reign. This
doesn't happen often.

Another way is evolutionary. Even legacy applications need updates as
business needs change. Take the opportunity for normailzing the tables
related to those applications as the need arises.

the last option is: leave well enough alone. If the applications are
unlikely to change, then why tinker with their data storage? Note that
some well designed applications occasionally have denormalized tables
for performance reasons.

ed

Where I am currently working, there are several unnorm