knitting-1268932_640We talked about how a closely coupled system becomes a stagnating point for a company that wants to perform releases in a more nimble way. The first issue that we will address is database sharing: several components accessing a relational database directly. In a successful business, software grows constantly, and that means new requirements and features constantly being improved and increased.

At some point, the team will realize that the old architecture does not hold any more to the scalability and stability needs for the components. Additionally, if new teams are being brought into the department and start working on the same database, changes on the structure generate impacts on each other’s performance and reliability.

Case 1 – Metadata-driven

The first and typical answer to this problem is making all queries dynamic instead of fixed. Rather than fleshing out a detailed and optimized request to the server, this job is delegated to another component. However, the recursive and reflexive algorithms required for this approach have a major caveat: high consumption of processing power and memory, which means that the tool will not scale correctly on high demand environments.

Case 2 – NoSQL could be an option

Eliminating the “relational” part of the equation means that there are no changes to the structure – as there is no fixed structure to begin with. Including a new attribute to the object increases complexity only in the control of null and empty values (which you should be doing, anyway).

The challenges within this approach lie on performing analytical research, and building up effective reporting services. Querying becomes non-trivial when you can’t expect consistent fields returned from your requests. Good data models are the biggest weakness for non-relational databases, and that could make this strategy wrong for your business.

Case 3 – N-tiered architecture

The most valid strategy is also the most expensive, in terms of time and effort invested. Since this approach alters the software architecture as a whole, we will take a look in depth on the next entry on this series.

Unraveling databases

Leave a Reply

Your email address will not be published. Required fields are marked *