Shifting Away From Tables, To Entity Models

RDBMS (Relational data management systems), simply put, most Database systems allow us to create data models of businesses in terms of rows and columns in a table. Tables can be ‘related’ to indicate dependencies of data between tables. RDBMS was one of the best things that ever happened to software abstractions. Every business domain has been modeled to be a set of tables and relations between them.

However, recently another paradigm is taking shape, called as Domain Driven Development, DDD for short, that emphasizes the importance of modeling a business in the domain of the business itself rather than dictated by abstractions tied to tables. DDD clout calls them “Entities” (not Tables).  In certain ways, I read this shift from RDBMS to Entity model as “shift from horizontal (table) abstractions to hierarchical (entity) abstractions”.

While Entity models may provide a better modeling, in a well designed database model, based on my experience, most of you may not find any obvious issues with current table models. And definitely no need to remodel your systems to embrace entity models, right away.

There may be lots of players in the Industry that are supporting Entity frameworks, but based on my current and recent work, two companies I must mention here.

Microsoft

Microsoft released ADO.NET based Entity framework and even made it easier to create those entity models from existing RDBMS tables. And almost every .NET project I have looked at recently is buzzing about DDD, ACL (Anti corruption layer) and Entity framework. LINQ is something can not be omitted, of course.

And on its Cloud offering, Windows Azure, Microsoft is providing both options. Azure Storage (read non-RDBMS and optimized for cloud) and Azure SQL (read SQL Server running on the cloud). That makes transitioning from an in-house application to the cloud smoothly.

Google App Engine

And Google App Engine doesn’t support RDBMS abstraction at all but only support Entity models. (No JOIN support in App Engine will force you to think different and prefer one over the other, whether you like it or not).

Google App Engine team aptly explains the scalability reasons behind moving away from RDBMS and creating its own BigTable.

Back to the Future for Data Storage

Building a massive, distributed datastore which can service requests at an extremely high throughput is something that we’ve focused on at Google. We created something called Bigtable that underlies the datastore in App Engine. The design for Bigtable focused on scalability across a distributed system so it may operate a bit differently than databases you’ve worked with before, such as not supporting joins. This isn’t an accident — when you build a system that can scale to the size that Bigtable can there’s no way to do a general purpose join on data sets that size and still have them be performant.

So does this mean the end of RDBMS abstractions?

As I mentioned earlier, I don’t see any reason to remodel existing systems right away. The abstraction in Entity models could still be carried out with existing Table models. Unless you got huge data sets and you have faithfully using the deepest normalization possible. And of course, only if the top most concern you have is scalability or performance.

And I am pretty sure RDBMS systems will stay for a longer time, as almost all data is currently stored in some form of RDBMS system. But Software modeling via RDBMS abstractions for sure, will change.