CODEWITHSUNDEEP
c#mongodbormabstractionnosql
Earlz
Earlz

Reputation: 63865

Is an ORM redundant with a NoSQL API?

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?

Upvotes: 42

Views: 23901

Answers (8)

Tom Van Eetvelde
Tom Van Eetvelde

Reputation: 1

I find the question a bit strange and upside down. The main purpose of an ORM is not to make abstraction of the relational database, but to embrace it completely. Let me clarify.

In the old days, relational (data modelling) was the first step in making software. The second step was to write the methods that would operate on the data model (in C eg.). (ANSI) SQL was used to interact with the relational database. If you stick to standard SQL, your code is independent of the vendor of the relational db, providing an abstraction layer of the type of database.

Then came along OO modelling. The word 'database' no longer holds then, as the data is stored in your classes (objects in memory). If you want to persist the data held in memory from time to time, the question rises which technology to use. If you go for a relational db, then you need an ORM layer to persist the data. So the ORM arises out of an OO modelling paradigm, not as some alternative way to query the database for the sake of 'abstraction'.

In the beginning, there was no ORM. So the ORM layer was handcoded every time. But as this need is shared among all OO modellers, a framework emerged to prevent handcoded solutions. Frameworks arise out of a common need when you follow the same paradigm (philosophy). So it is always important to know from which corner (philosophy) a framework comes from. If you take on the framework without the corresponding philosophy, you get a nightmare. This is what happened when C coders learned OO 'syntax' and kept on writing code with a procedural mindset, ignoring the paradigm shft of OO languages (that require to put the method into the data).

So if you have an OO (or DDD) model and have persistence needs, you can go for a nosql database if it requires less effort than an ORM solution on top of a relational db. You can even go straight for an OO database.

As a sidenote: ORM also serves the need to keep on supporting existing data stored in relational databases while the code (business model) has been rewritten to an OO style. If your project starts from scratch, there is no need to opt for a relational database per se.

Upvotes: 0

ficipa4914
ficipa4914

Reputation: 1

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 ...

Upvotes: 0

user1557698
user1557698

Reputation:

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/

Upvotes: 1

Dean Hiller
Dean Hiller

Reputation: 20204

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).

Upvotes: 1

Vivek
Vivek

Reputation: 21

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

Upvotes: 2

TTT
TTT

Reputation: 2375

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/

Upvotes: 2

Aaronaught
Aaronaught

Reputation: 122654

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.

Upvotes: 30

DevelopingChris
DevelopingChris

Reputation: 40798

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.

Upvotes: 0

Related Questions