Siddarthan Sarumathi Pandian

Full Stack Dev at Agentdesks | Ex Hashnode | Ex Shippable | Ex Altair Engineering

Jun 5, 2017

The DB holy grail is one of my favourite things to talk about. There isn't a single correct answer here, it depends entirely on your requirements. It's really about horses for courses.

First things first, is your data relational? If yes, go the RDBMS way. I just love the discipline that a RDBMS store enforces - foreign keys and not nulls for examples.

NOSQL gives you a lot of power (in the sense that, there are not really a lot of constraints from I've seen), so it's easy to get sloppy. Use it only if you understand it.

But, like Joe said, most companies these days usually have a combination of a SQL store and a NO-SQL store. At my previous job, the 80% of the data was in Postgres and the rest was in Mongo.

Gabor

developer

Jun 10, 2017

When I started to play with mongo db I quickly realized almost all data was relational. I had to connect users to almost everything at least. So here is my question to your question (First things first, is your data relational?) - Can you please give me a real-life example of any non-relational data?

Currently I prefer Postgres which has a built-in native support for BSON while still it is an RBDMS. I'm also playing around with graph dbs to check how important the relations (connections) are?

As you wrote at your previous job there was only 20% Mongo data. What kind of data did you store as noSQL documents? How did you connected them to all other sql tables?

Gabor, Now that think about it, I don't think any of us deal with non relational data (or I couldn't come up with one, most data we deal with is relational). What we do is put relational data is non relational databases, I would think.

I'm not quite sure if this is the best example of non relational data, but think of an application that runs tests cases on every github push and saves the console output to the db. Now, whenever the user logs into the app, you want really fast reads to millions of documents in the db, which in turn means faster reads. This is the kind of data we stored in MongoDB at my previous job.

Search Hashnode