Almost all software development companies create software for business use.
This almost always involves storing data, causing many developers to immediately think of a database.
This article intends to make you think about the role of the database whilst stimulating your curiosity about what the central part of your application should be as well as to add food for thought to the debate between database-oriented vs in-memory oriented developers.
Some architects strongly advocate establishing the data model before any development starts. But, how can you know for sure if your data model is correct if you haven’t first established your use cases and determined business rules with the client who should be the architect.
“How can you know for sure if your data model is correct…?”
The problem a database-driven approach causes is one of the reasons why design approaches like domain-driven design are preferred.
This approach also encourages the separation (into tiers) of domain logic and data source logic.
Secondly, any changes in a tier of your application won’t (and shouldn’t) affect the rest of the system.
Here is a quick list of points (the pro’s and the cons) of each approach:
- Good for mission-critical solutions where pure speed is vital (assuming the SQL queries are intelligently written)
- Portability could be an issue if vendor’s are changed
- Any changes has ripple effects, often up to the UI layer
- SQL is a poor language in which to write complex business logic
- Abstraction over storage mechanism
- Enables delaying decision about storage mechanism as far as possible, which is also what good architecture is about, as per Robert C. Martin (aka Uncle Bob)
- Avoiding vendor lock-in
- More maintainable (enables separation of concerns and encapsulation)
- Can speed up prototyping and initial development by mocking instead of using an actual database
- General mindset is towards testing of code, not the database
- Better exception handling
If for some reason your team decides to put business rules in your stored procedures (SP), the Single Responsibility Principle (S in the acronym SOLID) still applies where an SP should only do ONE thing and do it well! Similar to how Bjarne Stroustrup (creator of the C++ language) described a well-written function.
Writing clear and maintainable code should be the primary focus as the majority of applications are not mission-critical.
One can use the many code profilers available to determine “spots” where performance suffers, and optimise accordingly, i.e. sacrificing clarity for speed as per Martin Fowler.
Even so, clear and concise code will always be easier to refactor at a later stage.
SQL is an incredibly powerful language, and hasn’t changed much since its appearance in the 1970’s, but it is often much less clear to today’s developers when complex queries need to be fixed at 3am. A database is simply a storage mechanism (although flat files will often suffice too); it was created to store data, not business logic. It is because of this that I believe a database should be treated as a detail.
I hope the above has given you some food for thought and made you question what the center of your software universe is.