En este artículo de Peter Harkins titulado Rules of Database App Aging se indican los síntomas que padece una base de datos cuando sufre los cambios de la aplicación a la que sirve como contenedor de información:

1. Todos los campos se vuelven opcionales. De repente empiezan a aparecer campos que no se conocen y que deben terminar en la base de datos. Las restricciones de obligatoriedad se relajan para dar cabida a todo tipo de información que no se había previsto, perdiendo su inmaculado NOT NULL. Aparecen cláusulas de guarda por todos sitios y los left joins dan paso a outer joins. Este es el efecto más evidente sobre los datos hasta el punto de que es posible adivinar la edad de una base de datos por la cantidad de campos que retienen la restricción NOT NULL.
2. Todas las relaciones se vuelven muchos a muchos. De repente aparecen personas que necesitan dos registros de localización, o alguien se da cuenta que las categorías no son mutuamente exclusivas. Las relaciones definen las bases de datos modernas y en cuanto la aplicación empieza a usarse, surgen fuertes necesidades de urgar con su estructura, saltándose una normalización o duplicando un registro para mejorar el rendimiento.
3. Los textos explicativos también crecen. Los cambios introducidos exigen explicaciones que no estaban en las descripciones originales.

hasta que llega el día de reconstruir la aplicación desde cero, en el que algunos NULLs regresan, se devuelve la normalización de los datos y se simplifican las relaciones a uno-a-muchos, consiguiendo la perseguida consistencia. Y todo para que justo cuando entre en producción, a algún político de izquierdas le dé por presentarse de nuevo por otro partido de forma que no tenga cabida en la recién estrenada base de datos…

Ese es el motivo por el que las bases de datos orientadas al documento (CouchDB, SimpleDB,...) y sin una estructura definida nos parecen cada vez más y más atractivas.