What happens if you want to modernize and normalize your database by by
splitting big tables into multiple smaller ones.

What if your database is already normalized to 3rd normal form? What if you
have always employed 3rd normal form? Or in the event that you do vary from
3rd normal form, there is a good business case that justifies it?

In other words, what if you expect future changes to be column additions,

If you used a view which originally had the same columns in the same table
the original table, you simply have to modify the view (joining the new
tables together), but you no not have to modify any of your programs.

Hold on there. Weren't we just talking about splitting tables? If the need
to do that were to happen (which would be unlikely in a database that is
already normalized to 3rd normal form), wouldn't you likely need to change
the programs that maintain that data, anyway?

You do not even have to rework your updates.
Instead of triggers, which can handled inserts, updates or deletes on
files/tables can only be added to views.

Wouldn't instead of triggers add overhead to the process?

So you simply have to rework your view and add or modifiy 3 instead of
triggers (one for insert, one for update and one for delete) ... and voilà
that's it

So the design philosophy is to expect to add instead of triggers to
processes in the future?

I'd always expect that something like this will happen in the future

You may expect to add instead of triggers in the future, but I wouldn't. I
would not base decisions today on a design philosophy that a database which
is already normalized to 3rd normal form today, would need to be normalized
differently in the future.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.