D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Dear OO Purists: Yes, the Data Model is Important

Sunday, July 29, 2012 5:18 AM

My buddy Terry sent this tweet out:


I thought I’d write one. In my head, I imagine Terry has had some interesting discussions with some developers, strong OO types sitting with their checkered shirts and Docker khakis, their “Gang of Four” books under one arm, peering down their noses under their 10 year old glasses that they think are hipster but really just make them look like elitist fools from a by-gone era.

And so its with this image in my head that I write this blog post, so if you sense a tinge of vitrol in it, you’ll understand why.

Really, this should be a very short post. It’s unfortunate that we have people holding on to by-gone views that don’t match with reality. Here’s reality for any system:

There is a domain, something built in code that models the business entities and processes for a specific domain.

There’s also a data model, something that stores data in a way that can be consumed by domains.

***The Domain and Data Model do not need to map 1:1***

I remember back in my school days where we learned that if we had a class called Customer and it had properties like name and address, we should have a database table that is also called Customer and has those fields. Keep in mind that in some cases, this design is still valid. And by some cases, I mean very simple applications that are one database/one app/one domain.

But when you move to the enterprise, or even a single complex domain, things change. In an enterprise scenario you can have a single database be the storage for multiple applications, all coming from different business domains. Tables in the database might not even be devoted to one app/domain – it could be shared across all the apps!

There’s this idea that the database needs to model the domain. This is wrong for so many reasons! The business logic for an application should be…where?…say it again?…that’s right, IN THE DOMAIN! It shouldn’t be in stored procs, it shouldn’t be in data structures, it should be in code that is able to interpret and modify the data based on domain rules. With that said, the database still needs to adhere to certain structures – things like foreign keys, unique constraints, and so on. These are different than business rules in the domain though – they speak to ensuring integrity of the data based on relationships.

The reason ORM (Object Relational Mappers) have become so popular is because they make it easy to bridge the gap – the domain folks can be happy creating a rich domain filled with business rules, and the data folks can go ahead and design their database for *maximum performance* (more on this in a second). The ORM then bridges the gap between.

Now about performance. This is something that is the Achilles Heel of OO development. OO, by nature, is bloated and is not the most performant. Disagree? We’ll code a complex calculation in C# and F# (a functional language) and see who gets it done faster, with less code, and which performs better. To help counter this shortcoming, the database and data model come in. Here is where we want to optimize the read/writes to the database, ensuring that we’re focussing precious computing resources in the domain processing data and not storing it. A well created data model has real, substantial impacts to the performance of an application. Simply mirroring an OO domain in the database can remove any benefits of storing data within an RDBMS at all – might as well write to XML files on the server.

As much as developers hate to admit it, there really is a good reason for DBAs to exist. Yes some of them can be arrogant douchebags that do nothing but guard their precious database at all costs because “developers are stupid and don’t know what they’re doing”, but I’ve worked with many who are the opposite – they understand the value they bring, and appreciate it when developers recognize that as well. Together, applications can be developed with a rich domain and a very performant database – all to the benefit of who really matters, the end users who don’t give a rat’s ass about how the app was modeled – just that it works to requirements and meets their needs.

So listen OO designers: get off your high horses, shelve your Gang-Of-Four books for some more recent publications, and embrace the data model. A rich domain and a performant database can and should be the goal of every application developer. Purely OO design does not get us there.


# re: Dear OO Purists: Yes, the Data Model is Important

Actually, you are being bit old school....these are the same arguments of old. Anyways...

you said "might as well write to XML files on the server."

Well, effectively, this is exactly what NoSQL is :) and slowly people are using it as they tend to marry with a OO and functional design paradigm quite well.

7/29/2012 9:07 AM | Keith

# re: Dear OO Purists: Yes, the Data Model is Important

Keith - You hit the nail on the head: these *are* old arguments, and they shouldn't even be argued! Yet there are still people out there that haven't gotten to this stage yet, nevermind looking at in-memory databases (NoSQL).

And the reality is, in a world where the Enterprise is still focused on Oracle, SQL Server, and DB2 (and any other relational database platform), these arguments will be around for a while yet. NoSQL has a long way to go before its mainstreamed. 7/29/2012 4:48 PM | D'Arcy from Winnipeg

# re: Dear OO Purists: Yes, the Data Model is Important

What you really need are developers who understand how to build and tune their data model as well. You aren't really building the whole application if you are relying on a dba to design and provide your data model. You also won't be able to effectively build an application to scale if you don't understand how your underlying data system scales....

As for NoSql.....where to even begin. Anybody who prances around telling people that NoSql is the future and rdbms is dead/dieing is nothing but an extremist looking at the world through their narrow tunneled view (there are plenty of them around!). It's dogma.

Is there anything wrong with NoSql? Definitely not. We use MongoDB extensively at my company. Are they better than rdbms? In some cases they are, and in some cases they are not.

NoSql is to rdbms what C# is to Scala. They both have their strengths, and they both have applications where one makes more sense than the other. The one thing that you can be assured of is that neither of them means the death of the other. 8/1/2012 3:42 PM | Chris D

Post a comment