>>
So the problem lies in modifying table structure and programlines. Well, shit happens. You can't avoid this entirely with surrogate keys (you still have to modify table structure and programlines).
<<

Walter...

Why do you over-complicate the issue? If there is one thing you can hold constant, it is the methodology with respect to PK's. I don't care how much you change the structure, a very simple methodology overcomes the issue you bring up.

To illustrate, once a table has been named, once the db has gone into production, it is fixed. So in the case of an orders table, the PK would be an auto-incrementing integer named orderid, orderpk, or whatever you wish to call it. The point is that no matter how many columns you add/remove, the PK remains the same.

The issue you bring up is EXACTLY why the use of surrogate keys is a best practice. It is a practice that works in ALL situations. To have a way of handling PK's in one scenario and another way of handling PK's in another scenario is to uneccessarily over-complicate the issue. And as such, cannot be a value-added excercise. And, if a change-over from one way to another is necessary, not only is it NOT a value-added excercise, it is a value-detracting excersise.

The only point I agree with you is that shit happens. Yes, db structures and specs change. Development does not occur in a theorhetically-driven utopian vaccuum. That means however that ones methodlogies must be able to overcome and adapt to the point that unproductivity is minimized. And IMO, what you preach is the antithesis of this principle.


< jvp >