Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just read these lines-

  • If your data is object in nature, then use object stores ("NoSQL"). They'll be much faster than a relational database.

  • If your data is relational in nature, the overhead of a relational database is worth it.


So, how do I know whether my data is relational in nature or object-oriented?

share|improve this question
Tell us more about your data... – FrustratedWithFormsDesigner Jun 16 '11 at 13:41
@FrustratedWithFormsDesigner I think he's looking for general guidelines. – C. Ross Jun 16 '11 at 13:45
The line that talks about "key-value stores that will allow you to hold elegant, self-contained data structures in huge quantities and access them at lightning speed" seems to describe the "objects" data that should be used in NoSQL - basically it sounds like "self-contained" chunks of data with no references or relations to other chunks of data... I can't give good examples of this because it's not something I am used to working with (at least not in this context). – FrustratedWithFormsDesigner Jun 16 '11 at 13:55
Just got this link. Hope it has hints to answer-… – Gulshan Jun 17 '11 at 13:29
up vote 13 down vote accepted

At the risk of getting shot to pieces, I'll try a plain English definition.

"Relational nature" for me translates to: all the items of a particular type have pretty much the same attributes, which makes it quite easy to design a simple table, but all items into that table and then SQL to perform CRUD and retrieval. In addition, if your data can be modelled such that all items have one of a limited set of types, you can then define a relational data structure that corresponds to this set of types.

"Object nature" translates into: Items of similar type can have a wide variety of attributes, and these attributes can be of a wide variety in nature and type. Very often this could (with sufficient effort) be translated into a relational model, but a lot of the tables would be very sparsely populated and you would end up with very inefficient LEFT OUTER joins, which makes the performance of a relational database sluggish when compared to a NOSQL database.

I would have to say that from my point of view there is no strict line separating these two. You could probably find any number of examples that fall anywhere between the two extremes.

OK, so now I have opened myself up to snipers from all directions. Any comments welcome. Let's see whether we can improve on this definition together.

share|improve this answer
Actually as someone who initially scoffed at the simplicity of the question, I have to say bravo for an understandable and insightful answer. You should look into writing books. – Philip Jun 16 '11 at 16:18
Can we summarize this to "having too many LEFT OUTER JOINS in relational design" or not? – Gulshan Jun 17 '11 at 6:24
I would be hesitant to make such a simplification. It's one of the symptoms, but not the only one. – wolfgangsz Jun 17 '11 at 8:28
A bit of example please? – Gulshan Jun 20 '11 at 7:32
Let's say you store information about people. Any one person could have any combination of attributes from a set of 300. All of them can appear multiple times or not at all. Some of them are composed of other combinations of attributes, i.e. they are sets. And now you want to search for all people where a particular attribute is either not there or not of a certain value. That's the sort of thing that will drive your normal SQL query builder insane. – wolfgangsz Jun 20 '11 at 12:33

I tend to have a problem with the article you point to.

Part of the issue with ORMs is that they're hiding the way the data is stored to the developer, and they invariably strive for cross-DB functionality.

The first leads to mindlessly trying to hydrate the data, even if the underlying model is ccompletely broken. This introduce many bottlenecks in the process because it's bloody difficult to get either right. (Some have called ORMs the Vietnam of computer science.)

The second invariably leads to forgoing treats like domains with type checks, triggers, pl functionality and all sorts of things which, while in a different language, really belong in the database itself.

The end result is that ORMs will indeed suck (Data Mappers suck less), and ultimately convinces some users that ACID can be discarded, and RDBMS along with it. Go NoSQL. Err... Not. :-)

NoSQL has its uses, don't get me wrong. As a massively scalable cache, for instance, it's fantastic. :-)

Anyway, you might find these two discussions interesting, if the other side of the argument interests you:

share|improve this answer

The data is both.

(strictly speaking it can't be object in nature because it lacks behaviour, but we won't nitpick).

The decisions about storage of data in a RDBMS or NoSQL database depends more on how you intend to use the data, rather than the real 'nature' of the data itself.

If you intend to support all sorts navigational paths to the data, then you may want to store the data in an RDBMS because you will have different ways to access and present the data. You need the database to do a whole lot of heavy lifting for you. For example, 'Order' data may be accessed via customer, sales person, sku (item), date, region etc.

On the other hand, if you have minimal navigational paths, you may just store the entire object. For example, 'Basket' that is only accessed by the web front end and is not stored for long or analysed much, may be better suited to a NoSQL store. The sacrifice you make with (document or key value) NoSQL data stores is that you do without relationships between collections - if you don't need those relationships (for navigational paths, ad-hoc querying or reports) and take care of them in your app, then you'll be okay.

Of course, you can store data in both for different reasons, but that has its own drawbacks.

share|improve this answer

Data is not 'object in nature' or 'relational in nature'. Any kind of data can be represented in both relational or a object model/graph structure. What is appropriate depends on how the data is going to be used by the applications. Often you might even have both. For example data used on a website could be stored in a relational database, but on-demand loaded into a graph structure which is then cached in an in-memory key-value store.

The statement that object stores/NoSql will be faster than relational for some kinds of data is simply wrong. What matters is again how your application use the data, not the form of the data itself. An object store will be faster at loading an object graph stored as a unit, but will be much slower at ad-hoc querying across many objects, or updating properties on many object.

share|improve this answer

I think the key line from the article is :

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

It seems to me the author is making a good point in that if your code is for example getting the Number of customers in Spain for some bit of logic, you shouldn't populate a list of customers with all the customers in spain and then count the customer objects. (which an ORM might push you towards)

Obviously you cant tell from the customer data structure itself whether it will be used like that. so I think we should interpret 'data' to mean 'All of the information used by your application'. If this includes thing likes like aggregates or 'All X related to Y' then your 'data' is not suitable for the atomic NoSql approach

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.