+972 52-548-6969
Entity != Table
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.
Comments
Every DDD guy would probably say, that the assumption Entity == Table is false in the majority of Domains ;-)
"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
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.
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.
Elaborating on what was easier and/or more difficult would make for an interesting series or posts.
Hi,
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?
Nuno
Nuno: Lucene can do range searches, see lucene.apache.org/.../queryparsersyntax.html. I don't know how it does in internally though.
RavenDB then handles this for you when you index a filed that is numeric, see http://ravendb.net/documentation/how-indexes-work.
Comment preview