Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

NoSQL best practices [closed]

What are the best practices for NoSQL Databases, OODBs or whatever other acronyms may exist for them?

For example, I've often seen a field "type" being used for deciding how the DB document (in couchDB/mongoDB terms) should be interpreted by the client, the application.

Where applicable, use PHP as a reference language. Read: I'm also interested in how such data can be best handled on the client side, not only strictly the DB structure. This means practically that I'm also looking for patterns like "ORM"s for SQL DBs (active record, data mapper, etc).

Don't hesitate making statements about how such a DB and the new features of PHP 5.3 could best work together.

like image 805
Flavius Avatar asked Jan 31 '10 01:01

Flavius


People also ask

When NoSQL should not be used?

NoSQL also lacks in the ability to perform dynamic operations. It can't guarantee ACID properties. In such cases like financial transactions, etc., you may go with SQL databases. You should also avoid NoSQL if your application needs run-time flexibility.

Will NoSQL databases be around for the next 3 5 years?

NoSQL Databases in next 3–5 Years With many big companies like Amazon and Oracle providing NoSQL services the NoSQL database industry is about to grow in the coming years.


2 Answers

"NoSQL" should be more about building the datastore to follow your application requirements, not about building the app to follow a certain structure -- that's more like a traditional SQL approach.

Don't abandon a relational database "just because"; only do it if your app really needs to.

like image 32
Joel L Avatar answered Sep 20 '22 03:09

Joel L


I think that currently, the whole idea of NoSQL data stores and the concept of document databases is so new and different from the established ideas which drive relational storage that there are currently very few (if any) best practices.

We know at this point that the rules for storing your data within say CouchDB (or any other document database) are rather different to those for a relational one. For example, it is pretty much a fact that normalisation and aiming for 3NF is not something one should strive for. One of the common examples would be that of a simple blog.

In a relational store, you'd have a table each for "Posts", "Comments" and "Authors". Each Author would have many Posts, and each Post would have many Comments. This is a model which works well enough, and maps fine over any relational DB. However, storing the same data within a docDB would most likely be rather different. You'd probably have something like a collection of Post documents, each of which would have its own Author and collection of Comments embedded right in. Of course that's probably not the only way you could do it, and it is somewhat a compromise (now querying for a single post is fast - you only do one operation and get everything back), but you have no way of maintaining the relationship between authors and posts (since it all becomes part of the post document).

I too have seen examples making use of a "type" attribute (in a CouchDB example). Sure, that sounds like a viable approach. Is it the best one? I haven't got a clue. Certainly in MongoDB you'd use seperate collections within a database, making the type attribute total nonsense. In CouchDB though... perhaps that is best. The other alternatives? Separate databases for each type of document? This seems a bit loopy, so I'd lean towards the "type" solution myself. But that's just me. Perhaps there's something better.

I realise I've rambled on quite a bit here and said very little, most likely nothing you didn't already know. My point is this though - I think its up to us to experiment with the tools we've got and the data we're working with and over time the good ideas will be spread and become the best-practices. I just think you're asking a little too early in the game.

like image 127
Mark Embling Avatar answered Sep 20 '22 03:09

Mark Embling