41

with MongoDB (and I assume other NoSQL database APIs worth their salt) the ways of querying the database are much more simplistic than SQL. There is no tedious SQL queries to generate and such. For instance take this from mongodb-csharp:

using MongoDB.Driver; 
Mongo db = new Mongo(); 
db.Connect(); //Connect to localhost on the default port. 
Document query = new Document(); 
query["field1"] = 10; 
Document result = db["tests"]["reads"].FindOne(query); 
db.Disconnect();

How could an ORM even simplify that? Is an ORM or other "database abstraction device" required on top of a decent NoSQL API?

Community
  • 1
  • 1
Earlz
  • 62,085
  • 98
  • 303
  • 499
  • By the way, I kind of glossed over the parenthetical remark in my answer, but you said "other NoSQL database APIs worth their salt" - MongoDB is *very* different from something like bigtable or cassandra, and queries/mapping against those data stores actually tend to be much more *difficult* than SQL. Imagine implementing an entire data-driven app with nothing but `Dictionary<,>` instances. It's not that bad, but it's close. – Aaronaught Apr 22 '10 at 20:47
  • @Aaro well of course with a key-value database, the API is very simplistic. What I meant by worth-its-salt is that you don't have to generate your own JSON queries or similar low level things. – Earlz Apr 22 '10 at 22:03
  • Isn't that precisely what a mapper does? These features aren't built-in, not even in Mongo. – Aaronaught Apr 22 '10 at 22:31
  • @Aar.. hm... I suppose you may be correct – Earlz Apr 23 '10 at 15:25

7 Answers7

28

Well, yes, Object-Relational mappers are redundant with MongoDB because MongoDB isn't a relational database, it's a Document-Oriented database.

So instead of SQL, you write queries in JSON. Unless you really, really want to write raw JSON, as opposed to, say, Linq, then you're still going to want to use a mapper. And if you don't want to create coupling against MongoDB itself, then you don't want to pass actual Document objects around, you want to map them to real POCOs.

The mapping is much easier with a document-oriented DB like MongoDB, because you have nested documents instead of relations, but that doesn't mean it goes away completely. It just means you've substituted one type of "impedance mismatch" for a different, slightly-less-dramatic mismatch.

Aaronaught
  • 120,909
  • 25
  • 266
  • 342
  • @Cocowalla: I think [NoRM](https://github.com/atheken/NoRM) is the only one that's really worth the bother at the moment. That may change in a year or two. – Aaronaught Aug 29 '11 at 22:18
  • 1
    Your answer dodges the problem that the question asks about - which is to understand the need for a higher-level abstraction that an ORM provides. Just like RDBMS's, document-oriented databases need to store relations between entities. As stated in the MongoDB intro docs (http://docs.mongodb.org/manual/core/data-modeling-introduction/), you need to choose between embedding related data or referencing other documents. Related documents need subsequent queries, similar to lazy loading in Entity Framework. An ORM would be helpful in simplifying this, just as EF simplifies SQL joins. – Marchy Mar 08 '14 at 18:09
  • @Marchy: I wasn't "dodging" anything, and I don't agree that abstracting this away in MongoDB would be a good idea, as it would encourage developers to model data in a relational fashion when proper data modeling is the most crucial concern - as the very page you linked to clearly points out. Loading related documents one-by-one can kill performance, when most such databases have first-class support for minimizing round trips. Some, like RavenDB, even support query batching and relation-loading, which makes automatic lazy loading an even worse idea. I would not want to see that kind of "ORM". – Aaronaught Mar 08 '14 at 18:42
  • @Aaronaught Using an ORM is never optimally efficient, not even for SQL. That's not the point of an ORM. The point is to make it easy to deal with data (and security) via objects. If you want optimal, you always have to write native queries unless you're doing something incredibly simple. – geoidesic Dec 04 '15 at 06:17
2

I think an "ORM" on MongoDb can be useful, not only for "serializing" and "deserializing" objects into the db (Norm seems to do a great job) but also for making it more easy to execute aggregation queries.

It is nice if an "ORM" can generate MapReduce jobs for grouping and detecting duplicates. Some people have written code to automatically convert an sql statement into a mapreduce job: http://rickosborne.org/blog/index.php/2010/02/19/yes-virginia-thats-automated-sql-to-mongodb-mapreduce/

TTT
  • 2,365
  • 17
  • 16
2

Take a look on Kundera : https://github.com/impetus-opensource/Kundera, ORM over mongodb, cassandra, HBase.

Vivek
  • 21
  • 1
1

depends upon how mature is driver provided with the NoSQL database. This link discusses relevance of ORM tools for NoSQL database: http://xamry.wordpress.com/2012/08/10/sqlifying-nosql-are-orm-tools-relevant-to-nosql/

Amresh
  • 478
  • 1
  • 6
  • 28
1

Another solution is PlayOrm which can do joins as well when necessary with it's Scalable-SQL language(just adds a prefix to normal SQL basically to add partition info).

Dean Hiller
  • 19,235
  • 25
  • 129
  • 212
0

All you really need is a serializer/deserializer to make this work.

Norm has done a great job of doing just that. Makes it easier to take straight poco objects and just save them to mongo with a single line of code.

They call Norm an ORM, but its really just a poco to dictionary mongo wrapper.

An orm is just extra ceremony for these operations. If your data operations are abstracted into a repository, its going to be a non-issue either way, because converting to another backing store is an object per object, basis.

DevelopingChris
  • 39,797
  • 30
  • 87
  • 118
  • 4
    Who calls NoRM an ORM? I thought it was a recursive acronym for " **Not** an Object Relational Mapper." Or maybe it's just "Not a Relational Mapper", since the "o" is lowercase. Either way, it's definitely not an ORM! – Aaronaught Apr 22 '10 at 20:11
0

In python, I just read that there is a proposal to standardize libraries with APIs: https://discuss.python.org/t/request-for-comment-making-pep-for-nosql-databases/14772

More precisely, we are talking about a library to implement in turn other libraries according to the API described: https://github.com/MatteoGuadrini/nosqlapi

Perhaps, you can apply or transform these APIs in the C# language.

However, it would be advisable to have APIs in any language for NOSQL databases ...

ficipa4914
  • 1