The post delivery phase from a database administrators point of view involves the following points:
- Have the business rules changed and does the corresponding data model need to be changed?
- If the data model has changed, which tables in the data model will be affected?
- Do any depencies in the existing tables need to be altered?
- Do the tables have to be normalized?
In a traditional relational database, the user begins by specifying a series of column types and names for a table.
Information is then added as rows of values, with each of those named columns as a cell of each row.
You cannot have additional values that were not specified when you created the table, and every value must be present, even if it is as a NULL value.
You do not specify ahead of time what names will be in each table using a schema. In theory, each record could contain a completely different set of named values, though in practice, the application layer often relies on an informal schema,
with the client code expecting certain named values to be present.
The key advantage of this document-oriented approach is its flexibility. You can add or remove the equivalent of columns with no penalty, as long as the application layer does not rely on the values that were removed. A good analogy is the difference between languages where you declare the types of variables ahead of time, and those where the type is inferred by the compiler or interpreter. You lose information that can be used to automatically check correctness and optimize for performance, but it becomes a lot easier to prototype and experiment.