Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,131 | Comments: 45,563

filter by tags archive

Entity != Table

time to read 2 min | 237 words

I recently had a chance to work on an interesting project, doing a POC of moving from a relational model to RavenDB. And one of the most interesting hurdles along the way wasn’t technical at all, it was trying to decide what an entity is. We are so used to make the assumption that Entity == Table that we started to associate the two together. With a document database, an entity is a document, and that map much more closely to a root aggregate than to a RDMBS entity.

That gets very interesting when we start looking at tables and having to decide if they represent data that is stand alone (and therefore deserve to live is separate documents) or whatever they should be embedded in the parent document. That led to a very interesting discussion on each table. What I found remarkable is that it was partly a discussion that seem to come directly from the DDD book, about root aggregates, responsibilities and the abstract definition of an entity and partly a discussion that focused on meeting the different modeling requirement for a document database.

I think that we did a good job, but I most valued the discussion and the insight. What was most interesting to me was how right was RavenDB for the problem set, because a whole range of issues just went away when we started to move the model over.



Every DDD guy would probably say, that the assumption Entity == Table is false in the majority of Domains ;-)

Ryan Heath

"a whole range of issues just went away"

but which issues did you get back for it? ;)

For one, I can imagine that the referential integrity implemented (forced) by the sql databases is felt missing in document databases.

What (other) problems (in relation to Raven) did you encounter with this project, and how did you fix them?

// Ryan

Demis Bellot

Yeah that's pretty much why we should always write do our domain models-first so we know what compromises we are making in order to fit in within a RDBMS.

Frans Bouma

P. Chen defined 'entity' decades ago. It still stands, as it has nothing to do with implementation aspects (table, document, class etc.), but with what you recognize in the problem domain.

Jason Meckley

Elaborating on what was easier and/or more difficult would make for an interesting series or posts.

Nuno Lopes


I understand that RavenDB uses Lucene for indexing.

There are situations where we would like to search by field, say a range of dates with another value:

"SELECT * FROM POSTS WHERE PostDate >= @StartDate AND PostDate >= @EndDate AND BloggerID = "nbplopes";

How does Lucene perform with this? Does it perform a full scan or applies a smarter algorithm?

If it does not perform that well, can we use another kind of DB for index tables? Say MYSQL?


Comment preview

Comments have been closed on this topic.


  1. RavenDB Conference 2016–Slides - 17 hours from now
  2. Proposed solution to the low level interview question - about one day from now

There are posts all the way to Jun 02, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats