None of this is necessary if you select a durable schema. Whenever you think you need to "add a field" - add a whole new table and use joins anywhere you need access to the new field. You can't "delete" a field, but deleting a field usually means losing data anyway. You can't change the nature of a field without changing the domain that the data exists in. Keeping strict 1NF tables can really help avoid this. Your "update procedure" wouldn't be necessary at all.
What you're talking about is only reasonable for minor updates and/or temporary transitional updates. Over the long term, doing that will result in cludges piled on cludges, all sorts of fields in non-optimal locations and all sorts of empty fields, or the same kind of data stored in multiple places etc. It is more elegant to allow for all parts of a schema to change over the long term except perhaps for the smallest amount of control information, and said control table could just have 2 columns that store key/value pairs; eg, one key/value for version or other special clues that tell a program how to deal with the rest of the schema. -- Darren Duncan
