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 on 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 (at least, I only noticed it in the last year), 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, you may not find any obvious issues with current table models. And definitely no need to remodel your systems to embrace entity models.

Industry Support

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 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 Google App Engine doesn't support RDBMS abstraction but only support Entity models. (No JOIN support will force you to think different and prefer one over the other, whether you like it or not).

Update 02/19/2009: Google App Engine team 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 said earlier, I don't see any reason to remodel existing systems. The abstraction in Entity models could still be carried out with existing Table models. 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 abstractions for sure, may change.

Comments

[...] slide 23, the non-RDBMS bonus carefully. If you have read about my previous post on this topic, moving away from RDBMS/Tables, the point comes home pretty convincingly in this presentation. You can follow any responses to [...]
[...] wrote some time back in February Shifting Away From Tables To Entity Models discussing about fast adoption of Entity models for highly scalable systems moving away from RDBMS [...]

Popular posts from this blog

Newsworthy News in Red October : Dow Jones & Tax Dodgers

USCIS Selects Final H1B Petitions by Random Selection - Almost a 50% chance for each Application

H1B 2008:USCIS released Preliminary Numbers