Applying these principles will guarantee the schema is always in 3NF and is thereby a “good” schema.  In contrast, extensive application maintenance may be required. Also, repeated patching of application code may cause the application to “decay,”  i.e., become more convoluted and harder to maintain. In other words, the traditional wisdom will ensure no database decay but perhaps large application decay.

In the real world, NO SERIOUS DEVELOPERS use the traditional wisdom.  Some may use it for initial development, but none use it for evolution.  Specifically, developers are almost always interested in minimizing application maintenance, and will endure large amounts of data decay to achieve this goal.  To minimize application maintenance, the goal is to change the schema as little as possible (preferably not at all) by introducing data redundancy.  Hence, data is allowed to decay to minimize application decay.  Sooner or later applications (or the database) become so degraded that a complete project re-implementation is required.

The thesis of this project is that one should perform co-evolution of code and data.  Specifically, one should have a holistic metric that minimizes the composition of data and code decay. Sometimes one should focus on application decay and sometimes on data decay.  We have obtained six years of application and data evolution from B2W, a very large Brazilian e-tailer.  Our data encompasses about 70 iterations of their checkout software.  Our initial analysis justifies our thesis, because B2W appears to sometimes evolve application code, sometimes the DBMS schema and sometimes both.

We have mostly built an evolution tool that can quantify the decay in either dimension that any modification will entail.  On top of this tool, we hope to build a machine-learning-based recommendation engine that will suggest which evolution tactic to use.