Re: SQL and defining data structures

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,
only?

If you used a view which originally had the same columns in the same table
as
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
joined
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.