Software: Database development vs modern computing

The paramount concern for all software developers should always be striving towards a well-structured, quality codebase or else risk ending up with inconsistent, nonsensical code and constant requests against a database.

Modern computing power means many more calculations in a shorter space of time, which has the unfortunate effect of inefficient data access code not actually being shown up by the efficient code as it should be.

This becomes a compound issue with an ORM or an abstracted model, where the code you write doesn’t explicitly point to the fact that the method may select half the database, regardless of your requirement of it.

This may result in unintentionally inefficient code, but if the code runs then why bother concerning yourself with the burden that has been placed within the context of what you just wrote?

Efficient code, when it’s well written, thought out and refactored or re-engineered appropriately, is more maintainable and therefore less confusing to understand the intended implementation. It results in less strain on the database, and the quicker an application can respond to the user’s requests, the more trustworthy and useful it becomes.

This doesn’t mean go and denormalise all your databases; it means take time to think about how you implement the interaction with the database and strive to understand the implications of the code you write. Consider the delay it might cause in growing or already large datasets, slower connections, and the database developer who might be maintaining it in the future.

This also allows for better scalability, regardless of whether or not this was intended originally, bearing in mind that even a little-used application will have a growing database over time. This may sound like it will extend development time, but I firmly believe that the time is wisely spent due to the clarity of the final product.

The evidence of this can be painfully felt when testing, debugging, maintaining and expanding upon code that has not been crafted but rather fired out, coding by coincidence.

If a development team or individual can take the time to consider the words they weave and how the construction takes place, it will directly benefit the individual and should exponentially benefit the team and everyone who happens upon your code in the future.

Source: developer-tech