David wrote:
Later, you need to add an 'employed' boolean field, to reflect whether
an employee is still working at the company
Your new apps know the difference between employed and unemployed
employee, but old apps all assume that all employees in the table are
currently employed, and will want to send them pay checks, emails,
etc.
Furthermore, assume that this kind of change happens fairly often.
Would you make more views & rules each time the requirements change?
Would you need to update all the apps each time too?
Or are there other methods (version columns, etc) which can reduce the
work required in cases like this?
Well a couple of ways to tackle a change like this.
One is to move old employees into an employees archive table.
Old apps won't see the new table and old employee records.
New apps can union the two tables to get what they want.
Another way is to rename the employees table and replace it with a view
called employees which is defined with a WHERE employed = true. Leaving
it based on one table will make adding rules simple so that old apps can
insert to the employees table (which is now a view) and not know any
different. New apps can select from the new table name if they want
historic data.
It really depends on the change you need to make and how the simple way
to make the change will affect existing apps. You need to make these
choices as a change is needed to your app. Of course having some insight
as to what areas are likely to have changes can help you design now to
make it easier later.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
