In the context of a relational database, a column of a table is a set of data values of a particular simple type, one for each row of the table. The columns provide the structure according to which the rows are composed. For example, a table that represents companies might have the following columns:
ID (integer identifier, unique to each row)
Name (text)
Address line 1 (text)
Address line 2 (text)
City (integer identifier, drawn from a separate table of cities, from which any state or country information would be drawn)
Postal code (text)
Industry (integer identifier, drawn from a separate table of industries)
etc.
Each row would provide a data value for each column and would then be understood as a single structured data value, in this case representing a company. More formally, each row can be interpreted as a relvar, composed of a set of tuples, with each tuple consisting of the two items: the name of the relevant column and the value this row provides for that column.
Teams that have chosen to encapsulate access to their database via the use of a persistence framework will find it easier to react to database schema changes and therefore may discover they can tighten up the period between implementing a database refactoring within a development sandbox and in their project integration sandbox.
Because database refactoring is an enabling technique of the Agile Data method many of the cultural issues for adopting database refactoring are the same ones that you face adopting the Agile Data method in general.
Database refactoring is easiest in greenfield environments where a new application accesses a new database, and the next easiest situation is when a single application accesses a legacy database.
It supports emergent database design as well as the incremental improvement of existing, legacy database schemas, and it's a fundamental technique adopted by Agile DBAs (a term coined by Peter Schuh in a presentation at SD East in 2001).
Database refactoring is a multistep, iterative process, typically undertaken by an application programmer and an Agile DBA working in tandem.
When applying the Replace Columndatabase refactoring, you include the data definition language (DDL) for adding the PostCode column and the DDL to implement the triggers to maintain the values between the PostCode and ZipCode columns during the deprecation period.