18

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.

from-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

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

Improve this question
4
  • Tell us more about your data...
    – FrustratedWithFormsDesigner
    Jun 16, 2011 at 13:41
  • 7
    @FrustratedWithFormsDesigner I think he's looking for general guidelines.
    – C. Ross
    Jun 16, 2011 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, 2011 at 13:55
  • Just got this link. Hope it has hints to answer- highscalability.com/blog/2011/6/15/…
    – Gulshan
    Jun 17, 2011 at 13:29

4 Answers 4

Reset to default
18

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.

Improve this answer
6
  • 1
    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, 2011 at 16:18
  • Can we summarize this to "having too many LEFT OUTER JOINS in relational design" or not?
    – Gulshan
    Jun 17, 2011 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, 2011 at 8:28
  • A bit of example please?
    – Gulshan
    Jun 20, 2011 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, 2011 at 12:33
6

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.

Improve this answer
3

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.

Improve this answer
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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