What do you guys think of the whole NoSQL vs SQL debate? Anybody here have any experience in the real world using both?

NoSQL is a meme

SQL is the eternal DB king

Maturity of the technology for one thing: Mongo doesn't even allow certificate-based authentication.

It is also relatively easy to set up postgres (or a similar database) whereas Mongo seems more brittle (I might be biased there) and we ended up not configuring our own Mongo server but instead using it as a service. I wasn't a fan of that.

With Postgres we had severe performance issues due to a braindead database setup. I think they could have been easily fixed within that same system, given the proper effort. I was busy with other stuff at the time and didn't get my shot at it.

With Mongo, quite a bit of stuff which could otherwise nicely be handled within a database had to be done in Java code which I'm not a fan of.

In the end, it was really the "We'll cling to Hibernate instead of learning to use the DB properly" attitude which pissed me off the most. Of course that has nothing to do with Mongo.

Graph databases. That's the only thing SQL isn't good at.

NoSQL only caught on because people hate writing schemas. But most of the time your data has a schema and you should use SQL.

If your data is rows and columns then you probably want SQL. If you data is something else you might want NoSQL, or something different altogether.

Postgres has the capability to use json fields with indexing and search and mongo switched to a mongoloid non-free license so NoSQL dbs are useless now.

>With Mongo, quite a bit of stuff which could otherwise nicely be handled within a database had to be done in Java code which I'm not a fan of.
You mean Javascript. Otherwise I have no clue why it had to be specifically Java.

People who swear by noSQL would be much better served by a relational database. It's like a status symbol.

If you don't know that, means you don't need NoSQL

Also elastic search is pretty good at free text fuzzy search and cache. But it should not be used for data storage.

At my job we're using UNIVERSE/UniData, which you could say it's a NoSQL nonrelational multivalue database. It's blazing fast, although extremly clunky to work with, once you get the hang of it it's kinda neat.

I think he just meant that his project was in Java and he had to manually implement various SQL-specific features.
This is what I hate the most about NoSQL. Triggers, constraints, functions and virtual fields are really useful, yet mongo doesn't support them.

>hierarchical has applications
Cope.

I've been using MongoDB for about 5 years now.
IMO it's quite alright.
Not life-changing or anything, but at least it saves making and maintaining shitloads of tables.

Large systems using SQL can get extremely slow.
I get a daily dump from a client's SQL back-ended program which takes them 20 minutes to generate.
Takes me 2-3 minutes to import (mostly spend on parsing gigabytes of XML) and exporting from Mongo is near instant.

I hate NoSQL so much. I have to work with MongoDB and while being running smoothly and for the most part doing what it is supposed to do it, is a fucking cancer to write queries for it and our devs continue to migrate more and more stuff from SQL databases to NoSQL stuff.

>is a fucking cancer to write queries for

How?
In my experience is far less verbose than SQL where you have to join dozens of tables just to extract one item.

B I G D A T A

Guess you have never worked with aggregates?

Not him
Try to do some complex query that requires aggregation and gets some more information from database than raw data.
Eg. Given table of Users, Places and Events(including leave and enter), based on events, for each place calculate the amount of unique users that entered it in last 24h and amount of users that are currently there(their last enter event doesn't have an matching exit event).
This is not trivial in SQL, but is doable and works quite well. However I just couldn't write a query for Mongo that would do all of that on db-side in one query.

with mongo aggregate you can easily do the same, ofc if you think SQL or try to port 1:1 relational to non relational you're doing it wrong. What if you have to use cassandra or dynamodb? where you cant query unless indexes are present and data has to be in a certain way?

everything has a reason, I have lots of experiences in both SQL, noSQL, it really depends if your application is integrity-first or speed-first, but most of the devs coming from SQL have no idea on how to properly structure stuff in the other world.

also, OP stop asking on Jow Forums where everyone is just an uni reject without experience, peace out

>constraints
this is the only thing that is not present in nosql alternatives, the reason is quite absolutely obvious I don't need to mention it

Well I tried and I couldn't do it properly.
Maybe I didn't get something, but it wasn't my first try at mongo. I pretty much rewrote whole application to mongo from SQL because management thought it will be good idea. I think I learner most of what there is to learn, both about engine and nodejs driver. I've tried to use that aggregate method but what pains me the most is that virtual columns are client-side and whenever driver lose information about concrete type it loses virtual columns.
At the end it worked, but it was really ugly in comparison to SQL implementation and required some minimal client side computation.

I'm sure there wasn't any triggers and server-side virtual columns in mongo last time I've checked. When did they changed it?

honestly never had to use virtual columns (or maybe we call them another name) so I'm not sure what you mean - if you have little to no knowledge in both mongo AND node than it's likely your solution can be heavily refactored

docs.mongodb.com/stitch/triggers/database-triggers/

triggers are there, no idea on what would you use virtual columns for when you have views (and can do really complex aggregation without having to learn an ad-hoc language)

Don't you fix that by passing through a model instead of querying the NoSQL database directly?
I use Mongoose which is very simple but at least ensures I don't for example write a string value to an integer field.
It's not a complete Wild West out there in NoSQL land.

It's a column that doesn't have value stored but is evaluated as an expression or subquery when quered.
mongoosejs.com/docs/guide.html#virtuals

That looks promising.
But this isn't in the standard database server, is it? If I understand it correctly this is some proprietary cloud platform.

That's what I was doing. You lose virtual columns when you aggregate documents IIRC.

Most RDMS have NoSQL support.

Something like Postgresql has had 30 years of fucking development. It's a lot easier for them to add json support than it is for something like MongoDB to add SQL support.

Seriously just use Postgres. Horizontal scaling is a fucking meme for basically everyone who isn't Alibaba tier. And even then you can do it with Postgres but it's just a pain

It doesn't need to be either or. Why have a toolbox with just screwdrivers in it? For a long time, databases automatically meant SQL and relational. The nosql movement was just a reaction against that retardedness.

Don't use MongoDB though. It's just shit. Dirty reads?! WTF??

Since SQL databases now have all important capabilities for 99.99999999999999999999999999999999% of all use cases, everyone else might just give up.

itt dumb zoomers that don't know why nosql was invented in the first place. Enjoy your max of 200 inserts per second on your SQL server.

Is there any actual use for NoSQL besides migration of big data?

If you get into a weird situation you can always pay SQL experts to unfuck your shit.

With NoSQL, when you get stuck, you have to hire SJWs that specialize in whatever hipster database you picked.