Building SOLID Databases: Introduction
The SOLID design approach is a set of principles developed in object-oriented programming. This series will explore the applicability of these principles to Object-Relational databases, and contrast the way in which they manifest from the way in which they manifest in the application layer.
You can't program a database like you'd program an application. The database essentially serves two twin functions: a persistence store, and a model of information derivable from that store. The ACID consistency model therefore limits what sorts of programming you can reasonably do in the database because it is a bad idea, outside of logging, to mix transactional and non-transactional side effects.
As an information model, the approach taken by applying these approaches then is relatively different. One way to think of it is that if object oriented design might be seen as a triangle, applying this in the db requires turning that triangle upside down so you have a flat base to build your application on.
This series will look at applying SOLID principles to object-relational database design, comparing and contrasting the way in which the principles get applied to that of general software development. Many aspects of relational design in fact play into these topics and so one ends up with a very different mix than one might have with pure object-oriented design.
In general this series continues to look at relations as sets of objects rather than sets of tuples. This means that the question is how we define data structures and interfaces so that we can bridge object and relational worlds in the database. The SOLID principles are good starting points but the sort of logic done is fundamentally different and so they are applied in different ways.
Welcome to the series. I hope you enjoy it.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)