Changes to database structures are best performed in a coordinated fashion as the application processes that support the new functionality are rolled out into production. In a relational database, While the “work” involved in adding a column or a table to a relational database is actually minimal, is minimal, often there are circumstances where developers and DBAs create additional columns and additional tables because “future needs” are anticipated. Sadly, this “proactive” effort results in databases littered with half-formed ideas, fits-and-starts, and scattered-about columns and tables that provide no meaningful content.
In a relational database, the “work” involved in adding a column or a table is minimal. Yet time and again there are circumstances where developers and database administrators create additional columns and additional tables not currently needed, but included because “future needs” are anticipated, and they are creating these things ahead of time simply to “save” time and work later. These people consider they are being proactive.
They may even believe that they are offering proof of their ability to be ahead of the curve. Because someone expressed a passing need for some column, these developers and database administrators have accommodated that request. More often than not these “do-gooders” are not responsible for enhancing the application to populate these new items. Thanks to their efforts, the database for a given application ends up having more tables and more columns than are actually used. These additional elements either remain empty, or are populated with a default for 100% of the instances.
Sadly, this kind of proactivity results in databases littered with half-formed ideas, fits-and-starts, and scattered-about columns and tables that provide no meaningful content. These unused data potholes are the structural flotsam and jetsam of good intentions. Someone new to a group, coming in to understand databases with this kind of graffiti, is generally slowed down in knowledge-gathering as they work their way through these data minefields. All columns look alike, so to say; if a column exists, it is only expected that it serve a purpose and provide value to the user community.
Often specific individuals need to be tracked down, as they may be the only ones who can verify that “Yes, this is not meaningful” and, “Yes, this was never supported” before the new investigator can move on to other issues. Adding insult to injury, if a time should come when these future-ideas indeed need to be supported, it is generally uncovered that the existing placeholder tables are not exactly right. After all, the columns were added when only a beginning thought might have been expressed, so exact requirements may never have been fully explored. Therefore, these time-saving structures either need alteration, replacement, or worse – they are forced into work unchanged, in their existing and insufficient form. Maybe it is fortunate that most often the day never comes when these anticipated features are utilized. Regardless, in “saving” work, it generally creates more of the wrong kind of work.
Adding columns and tables within a relational database environment is a simple task. Simple in that to write, even by hand, and subsequently execute the commands making the change within the physical database management system is a matter of trivial effort. Often more time is spent synching up the documentation related to such a change than the time involved to execute the actual database alterations.
Changes to database structures are best performed in a coordinated fashion as the application processes that support the new functionality are rolled out into production. In an environment that has a vigorous change management process, this should be the natural course of events. The items going into a database should match the things the database supports. When individuals feel compelled to make database changes long before the code that supports populating these elements is ready, that is a symptom of something unhealthy in the development lifecycle.
And it should be investigated in order to track down the root causes of this unhealthiness. Ideally, once those issues are uncovered, improvements can be offered and implemented to address them. Avoid victimizing your database, leaving it over-served and awash with data voids caused by thoughts of what-might-be-needed-later-but-never-comes-to-fruition.