This might be a silly question, but I’ve reading a little bit about NoSQL databases on the past few days and I’m trying to understand when really they help us. One thing I’ve realized though is that it seems that NoSQL databases are closer to OOP than RDBMS.
I say that because usually when we deal with OOAD we don’t get a finished version of the model upfront. The model changes lots of times before getting to the real thing. I’ve even questioned about this here on Programmers.SE. With NoSQL, however, this seems the most natural thing, since the database can also change without much trouble.
Also, for a first try with this kind of technology I’ve created one MongoDB database and the data was being saved like POJO, so that it seemed much more close to object oriented design.
In that setting, NoSQL is really a good idea when working with OOP or it’s just a good idea in cases where we need the database to scale, to be accessed by many users and all of that stuff?
3
There is no such thing as NoSQL. There is a myriad of new database technologies grouped under that label, and they all work completely different.
But when you are talking about document-oriented, schemaless databases like MongoDB, which are one subset of NoSQL, then yes, these are often more suitable for modeling object-oriented hierarchies than relational databases, because they are usually less affected by the Object-relational impedance mismatch problem. When you have a class hierarchy with classes inheriting from other classes, these classes usually have some fields in common, but other fields which are unique to certain subtypes. When you try to cram all of these objects in one relational database table, you will have to create lots of columns for fields which only apply to a small subset of entries and will be NULL for all others. An alternative would be to use a separate table for each subtype, but this will become ugly when you try to query all objects of a certain base-class regardless of what their sub-class is.
An even better match than schemaless databases are pure object-databases, but these are usually quite exotic technologies without widespread use. Also, they are often bound to a specific programming language which hinders interoperability with systems programmed in other languages.
But how well you can model your data is only one aspect which should be taken into account when choosing a database technology. There are often a lot of other requirements in a project which give reason to favor one database technology or the other.