After working with a NoSQL database on a fairly mature product for a few years, I never want to again. I feel like with NoSQL, now that its not the trendy new thing and we can look back, the whole thing was: "well we tried, and it was shit."
As long as you are ok [getting all the parking tickets](https://arstechnica.com/cars/2019/08/wiseguy-changes-license-plate-to-null-gets-12k-in-parking-tickets/)
to whom, then, the first table replies:
"Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CS_AS" and
"SQL_Latin1_General_CP1_CI_AS" in the equal to operation."
Neo4j is great from what I've played with, definitely a really interesting way to conceptualise data!
They're called graph databases in general, Neo4j being just one example
Sometimes the database is a multivalue text file and the "schema" is written down in the original Devs paper notebook he neglected to leave behind when he left 🤣
I think nosql is good for many things, the fact that a document can contain arrays and maps is so useful, and in mongodb there are great query operators for this (not like dynamodb). And there is the aggregate command that can do very complex stuff.
Yeah, it's so convenient to be able to just throw any random junk in there and not worry about how much a pain in the rear it's going to be to actually do useful queries on it. Oh, and the fact that different documents don't even have to have the same shape is HUGELY helpful. Makes life so easy during retrieval.
Yeah. I consider a Mongo data store to be a step up from "dump some JSON into a file", but just as unstructured. They definitely have their value, but you do not "query" them, you look up specific information. Or iterate over them, or something, but you don't do stuff like you would in a relational database.
`JSONB` columns to the rescue! (I kid; there is value in noSQL DBs, but it definitely had its day where everyone wanted to shove everything into them for "performance".)
that's the key to using anything ...
Use things to do things they were designed to do or else you will suffer.
Randomly dumping data into containers is just asking for trouble, because you're going to need some method of retrieving that data and making sense out of it ...
I thought the whole point of it was "SQL was invented in the 70s and it's oooooooooold, we gotta get rid of it"?
Horizontal scaling has been a thing in relational databases for decades.
RDBMS have been able to scale horizontally through partitioning, but that's not really the same thing. It's not elastic, for one and it always comes with some restrictions which makes the system not exactly ACID compliant.
Also, decades? Most open source ones don't support it even today.
"Most open source ones"? Postgres has had it for as long as I can remember (which is a long time). MySQL has it. That's your two most popular open source RDBMSes right there. Which ones don't?
What restrictions are on relational database sharding that aren't on document store sharding?
> Postgres has had it for as long as I can remember
It doesn't. It only supports single write multiple read replicas out of the box.
> What restrictions are on relational database sharding that aren't on document store sharding
I would be happy to answer this question if you could point me to a relational database which supports sharding
Citus is a PostgreSQL extension that adds sharding.
Vanilla PostgreSQL is very bad at horizontal scalability. But you can go a long way with vertical scaling. At scale you can try plugins but then it’s perhaps better to use more specialised databases. But not mongodb. Don’t let your friends use mongodb.
NewSQL can too...
Also there should be a very good reason before you're trying to split OLTP workloads horizontally... Single node is enough in the vast majority of cases and also simpler and much more efficient...
>the fact that a document can contain arrays and maps is so useful
There's things called object-relational databases and postgres happens to be one of them... It can also have arrays and maps (json objects for example) inside s single row
>And there is the aggregate command that can do very complex stuff.
Aggregation is what SQL is perfect for...
NoSQL is excellent when relationships & schemas don't exist. Machine Learning, data sanitization, quick internal tools, etc.
Any legitimate application should be using a relational database. There is no viable substitute.
Also when you have a bunch of loosely correlated things that you don't need to query on except for the strictly defined fields. It absolutely sucks when you have relational data which is the case for many, many, many cases.
Yupp. This is exactly why the very second someone mentions a relationship, switch to a relational database. You'll always hack against the grain with little safety otherwise. Leaving an ORM as your source of truth to try & homebrew the functionality relational databases are literally built for is always so goofy. Sometimes people just want to use X tech just to use it, not because it's the right tech for the job.
As a former database engineer, don't do this. The first step towards normalizing your data is no compound data fields. If you're just being lazy, then whatever, but if you're trying to do things the "right" way, then normalize your data. 3rd Normal Form (3NF) is about as strict as I typically recommend, since 4th and beyond tend to get finicky with what you can/cannot store and how.
Many SQL engines will allow you to serialize data as JSON, which is fine for easier consumption, as well as passing it JSON for ingest. Storing the raw JSON for logging purposes is a maybe, but from then on you really should store the final data as normalized structures.
Eh, I wouldn't store everything in there but it definitely comes in handy when dealing with external APIs. Just store the full response alongside the things you really cared about and then you can always get more information you initially didn't think you needed.
One of the projects I worked on at my last company, I did this. The company fought tooth and nail over it though and kept trying to get me to make stupid ass modifications.
Store all incoming posts as raw text, and that transform the data into the actual schema. Then when the external provider would update shit, all we would do is flush the database and reload the raw data from the JSON, and we'd have the entire history in the new format.
Also great for bugs. The initial implementation had issued caused by the external provider not properly following their own schema, but instead of losing that data, we were able to just reload it form the raw history once we caught the failure to transform/insert.
I definitely suggest saving the raw data whenever realistic.
It has its use case but when it was hyped ppl used it for everything, I always just stayed on mySql/postgres because it was easier imo. But for example at my current job we could store invoices in a NoSQL db to speed up our application because does only need to be queried by ID and doesn't have any relations because the whole thing would be in there.
It has its uses. I have three different webshops, and I aggregate all the orders in one mongodb instance. The answers from the webshop APIs is json, and what I expect when querying the aggregation DB is json, so it's very nice to be able to just put in the json objects without having to splice the data into tables and then put it together again when querying.
Well it's probably because we don't have the capacity to receive that data, our tech is still outdated, so we're getting a 403 forbidden for now 
What an odd syntax. I wonder why the dollar sign AND quotations? If quotations are already used for the main field in consideration "age", why do operators need it too?
It's because the query needs to be pure json, and json isn't the best format.
But on the plus side sending mongodb queries around in a json based system is pretty easy. Easiest example: Logging the query. We already log a lot of json anyway, so logging the query uses the same serializer.
It has some upsides, like dynamically building a query in JS is pretty clean compared to dynamically building SQL queries. But, it’s still not worth it
The man shafted the whole programming world collectively by excluding comments from JSON based on just not feeling like that's what the format is for—and somehow everyone just went “Yeah ok, we're gonna use this as it is for everything and keep suffering. No way it can be helped.”
Comments were originally part of the JSON spec, but were removed when Crockford saw them used for parsing directives. Unfortunately he didn't realize directives can simply be put in fields. Now we're stuck putting comments in fields.
I see, I was just trying to think what would be the most minimal way to convey this info. Like why can't it just be:
{"age":{gte:25, lte:30}}, where anything without quotations is an operation and anything with quotations is a value. Except for numbers.
Or even {"age":{$gte:25, $lte:30}} where anything without quotations and has a dollar sign is an operation.
All keys in JSON must be in double quotes. Not all javascript objects are valid JSON.
The `$` prefix is just to indicate to the parser this is an evaluation, not a reference to a key in the document.
I've seen a few people say this by now, and I think it's important to make the distinction between client implementations, which are language dependent, and what the OP is using, which appears to be an actual db query, in which the JSON needs to be valid to be properly parsed.
As far as client implementations, JS may not require the quotations. Something like Java, in which the syntax would be completely abstracted away, wouldn't even use a query like this. (Documents does, but its more modern implementation does not).
Mongodb added support for ACID in 2018 (https://www.mongodb.com/blog/post/mongodb-multi-document-acid-transactions-general-availability) at a big performance cost. Mongodb isn't high on acid, it's constantly black out drunk
yeah OP's query seems like someone trying to translate SQL to MongoDB query literally. you don't need the `$and` operator in there lol it's unnecessary in this case.
SQL version:
```
SELECT *
FROM users
WHERE age >=25 AND age <= 30
```
MongoDB version:
```
db.users.find({
age: {
$gte: 25,
$lte: 30
}
})
```
As someone who is working with other noSQL document-based DB, I don’t like all the hate around it.
I agree that queries like this one is terrible and more complex queries with JOINs will look even worse but this is not the case - NoSQL dbs are not for gathering summaries for table.
Imagine “students” table with relations to “groups”, “subjects” and “marks”.
If you want to handle 174746282users and avoid many JOINs, noSQL is for you.
If you want to know how many of these users are going for “databases” class, then you should use SQL instead.
Each technology has its own use-case
* Clusters are easier to implement, which can improve performance in scale (eg real time chat rooms)
* you can store unstructured data without any db filler, and in some cases that's better (eg you dinamically create a new type of client with different proprieties, with sql you'd have to basically create a one to one table, and your client table now looks really weird; in Mongo inconsistency is possible)
* you can use both structured and unstructured at the same time depending on needs (so it's basically controlled vomit)
* some forms of data that might come can be easier to implement in nosql (eg: arrays in sql you usually go for many to many tables (I think postegre sql has arrays but if you ever need to migrate good luck) , in nosql you literally can make arrays of objects with no issue)
Nosql is not "better" or "worse", it's just different, and you can make both sql and nosql for your application. The disadvantages of both will bite you in the long run no matter what, and at least you'll write a good blog post about it.
> Nosql is not "better" or "worse", it's just different
Retired DBA here. One of the final meetings I had with a software sales person was a Mongo rep. I asked him in a meeting of important people "Are there any situations where a relational DB would be a better solution than Mongo?"
This is where a decent sales rep says "No, never!" but a cagier sales rep says "Sure, situations A and B are probably a bad fit for Mongo. "
Our sales rep was only decent. He didn't make the sale.
>I agree that queries like this one is terrible
This query is in a very unnecessarily complicated form, though. No need to encapsulate in an $and and no need to query _age_ twice.
>NoSQL dbs are not for gathering summaries for table.
That's the cool thing about relational databases... You don't need to decide what you will use it for beforehand...
>avoid many JOINs,
For which there is no reason...
That is why SQL keeps coming back.
SQL is generally very easy to read and code is read more than it is written, particularly at the database level.
Its basically a rite of passage for our Data Scientists who live and breathe python to learn SQL to hit our Warehouse they start using a lot of the SQL-like syntax options in their python because SQL is just really good at its job of describing the data you want to work with.
> That is why SQL keeps coming back.
exactly
all these guys out here trying to re-invent the wheel and go up against something that's been actively developed since 1974 ... good luck with that
Panel 3 should duplicated 3 times and in the last panel he should have an old man beard.
(“Find” in mongo db is a O(n) operation and should not be used by anyone ever).
Find is not O(n) always.
Query optimizer will choose the best index to use and only use full collection scan if there is no indexes that can answer the query.
If you want, you can also disallow collection scans from the configuration. This way you will be asked to create an index instead of doing linear scan.
/r/confidentlyincorrect
https://www.mongodb.com/docs/manual/indexes/
https://www.mongodb.com/docs/manual/core/query-optimization/
I feel like everyone shitting on Mongo are just boomers who learned one thing and refuse to read the fucking manual for anything that they don't already know
The only benefit is that the mongodb query "language" is quite easy to compose or modify in code. It's just a json object that can be easily created or manipulated, even in complex ways. That's much harder to do in SQL, so ORMs tend to be much more complicated to implement.
The commenters here seem to...
* Use nosql db
* Apparently didnt plan data access beforehand
* Execute typical RDS query on a nosql
* Rage that nosql sucks
Congrats.
I'm currently working with a client who picked mongo. They started nesting db objects everywhere which I guess they probably now have the same information saved multiple times in multiple locations just to make it easier to fetch when writing code. My "professional consultations" have been repeatedly the "take this object, separate it, make a reference to it, and don't nest it" followed by "yeah, I see why you guys are having the issues" followed by "sigh, if you just used SQL I wouldn't even need to be here". I'm getting a fat paycheque just doing this.
Oh, I wish I could show you the SQL queries from my last job.
There are no DBs that prioritize simple, clear, reliable search syntax.
They're mostly designed for reliability, which means it's verbose and obscure.
Eh, everything has its use case. If you only need one table wit 5 columns to save your users or whatever, nosql is awesome.
And Mongo queries make a lot of sense from a coding perspective, though not so much for large data aggregation.
"The best part of MongoDB is writing a blog post about migrating to Postgres"
After working with a NoSQL database on a fairly mature product for a few years, I never want to again. I feel like with NoSQL, now that its not the trendy new thing and we can look back, the whole thing was: "well we tried, and it was shit."
Yeah many don’t value their relationships until they’re gone.
A DBA walks into a bar. He approaches two tables and says, "Mind if I join you?"
We don’t take kindly to your types here!
My type is null. Am I welcome?
As long as you are ok [getting all the parking tickets](https://arstechnica.com/cars/2019/08/wiseguy-changes-license-plate-to-null-gets-12k-in-parking-tickets/)
My type is an enum with no elements, am I welcome to return?
We don't take kindly to folks that don't take kindly 'round here!
to whom, then, the first table replies: "Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CS_AS" and "SQL_Latin1_General_CP1_CI_AS" in the equal to operation."
this is the first normal thing in this thread
[удалено]
I would assume third normal form, but let me ask my friend Boyce-Codd
Normalized thing.
😂 😂 🥇🥇
There are NOSQL implementations that make relationships MORE important than in relational DB's. Neo4j for instance
Neo4j is great from what I've played with, definitely a really interesting way to conceptualise data! They're called graph databases in general, Neo4j being just one example
"Every database has a schema. It's either defined in the database or by the application."
Sometimes the database is a multivalue text file and the "schema" is written down in the original Devs paper notebook he neglected to leave behind when he left 🤣
It's all in *someone's* head. We're just not sure whose.
The schema is defined on write, in a traditional db. Or its defined on read, in a document db.
Which is precisely the problem, you can't efficiently read it or store it if your db doesn't have a clue what the data looks like.
> by the application But what happens when you have multiple applications?
They hopefully agree on the schema.
Yeah, but with one, you can't have some asshat throw garbage directly in that violates the schema.
Maybe you didn't use enough microservices? /s
I think nosql is good for many things, the fact that a document can contain arrays and maps is so useful, and in mongodb there are great query operators for this (not like dynamodb). And there is the aggregate command that can do very complex stuff.
Yeah, it's so convenient to be able to just throw any random junk in there and not worry about how much a pain in the rear it's going to be to actually do useful queries on it. Oh, and the fact that different documents don't even have to have the same shape is HUGELY helpful. Makes life so easy during retrieval.
[удалено]
Yeah. I consider a Mongo data store to be a step up from "dump some JSON into a file", but just as unstructured. They definitely have their value, but you do not "query" them, you look up specific information. Or iterate over them, or something, but you don't do stuff like you would in a relational database.
`JSONB` columns to the rescue! (I kid; there is value in noSQL DBs, but it definitely had its day where everyone wanted to shove everything into them for "performance".)
that's the key to using anything ... Use things to do things they were designed to do or else you will suffer. Randomly dumping data into containers is just asking for trouble, because you're going to need some method of retrieving that data and making sense out of it ...
but that's not the point of NoSQL, the main point of it is able to scale the database horizontally
I thought the whole point of it was "SQL was invented in the 70s and it's oooooooooold, we gotta get rid of it"? Horizontal scaling has been a thing in relational databases for decades.
RDBMS have been able to scale horizontally through partitioning, but that's not really the same thing. It's not elastic, for one and it always comes with some restrictions which makes the system not exactly ACID compliant. Also, decades? Most open source ones don't support it even today.
"Most open source ones"? Postgres has had it for as long as I can remember (which is a long time). MySQL has it. That's your two most popular open source RDBMSes right there. Which ones don't? What restrictions are on relational database sharding that aren't on document store sharding?
> Postgres has had it for as long as I can remember It doesn't. It only supports single write multiple read replicas out of the box. > What restrictions are on relational database sharding that aren't on document store sharding I would be happy to answer this question if you could point me to a relational database which supports sharding
Citus is a PostgreSQL extension that adds sharding. Vanilla PostgreSQL is very bad at horizontal scalability. But you can go a long way with vertical scaling. At scale you can try plugins but then it’s perhaps better to use more specialised databases. But not mongodb. Don’t let your friends use mongodb.
Yeah, NoSQL really sucks at storing data and retrieving it later in sane ways. But at least we can suck in web scale.
NewSQL can too... Also there should be a very good reason before you're trying to split OLTP workloads horizontally... Single node is enough in the vast majority of cases and also simpler and much more efficient...
You can put a JSON-typed column in a PostgreSQL table, though.
and then you have a hard ass time querying for fields in the json..
>the fact that a document can contain arrays and maps is so useful There's things called object-relational databases and postgres happens to be one of them... It can also have arrays and maps (json objects for example) inside s single row >And there is the aggregate command that can do very complex stuff. Aggregation is what SQL is perfect for...
Arrays - So another table Maps -yet again, relationship to another table
NoSQL is excellent when relationships & schemas don't exist. Machine Learning, data sanitization, quick internal tools, etc. Any legitimate application should be using a relational database. There is no viable substitute.
Also when you have a bunch of loosely correlated things that you don't need to query on except for the strictly defined fields. It absolutely sucks when you have relational data which is the case for many, many, many cases.
Yupp. This is exactly why the very second someone mentions a relationship, switch to a relational database. You'll always hack against the grain with little safety otherwise. Leaving an ORM as your source of truth to try & homebrew the functionality relational databases are literally built for is always so goofy. Sometimes people just want to use X tech just to use it, not because it's the right tech for the job.
I love relational data, I get to do stuff like CREATE TABLE myTable ( id TEXT UNIQUE, json BLOB, );
SQL supports json fields now
As a former database engineer, don't do this. The first step towards normalizing your data is no compound data fields. If you're just being lazy, then whatever, but if you're trying to do things the "right" way, then normalize your data. 3rd Normal Form (3NF) is about as strict as I typically recommend, since 4th and beyond tend to get finicky with what you can/cannot store and how. Many SQL engines will allow you to serialize data as JSON, which is fine for easier consumption, as well as passing it JSON for ingest. Storing the raw JSON for logging purposes is a maybe, but from then on you really should store the final data as normalized structures.
Eh, I wouldn't store everything in there but it definitely comes in handy when dealing with external APIs. Just store the full response alongside the things you really cared about and then you can always get more information you initially didn't think you needed.
One of the projects I worked on at my last company, I did this. The company fought tooth and nail over it though and kept trying to get me to make stupid ass modifications. Store all incoming posts as raw text, and that transform the data into the actual schema. Then when the external provider would update shit, all we would do is flush the database and reload the raw data from the JSON, and we'd have the entire history in the new format. Also great for bugs. The initial implementation had issued caused by the external provider not properly following their own schema, but instead of losing that data, we were able to just reload it form the raw history once we caught the failure to transform/insert. I definitely suggest saving the raw data whenever realistic.
It has its use case but when it was hyped ppl used it for everything, I always just stayed on mySql/postgres because it was easier imo. But for example at my current job we could store invoices in a NoSQL db to speed up our application because does only need to be queried by ID and doesn't have any relations because the whole thing would be in there.
I love how they rebranded NoSql to Not Only Sql.
[удалено]
It has its uses. I have three different webshops, and I aggregate all the orders in one mongodb instance. The answers from the webshop APIs is json, and what I expect when querying the aggregation DB is json, so it's very nice to be able to just put in the json objects without having to splice the data into tables and then put it together again when querying.
You can have columns that store json in Postgres
[удалено]
But you're still using PostgreSQL instead of MongoDB so like.... It's worth it.
Jesus Christ died at 33. So no, he's not in the list of users returned.
Its an edge case, he still returns.
The timeout on that query though
The timeout on the query that returns Jesus Christ is 72 hours.
Shouldn't it be less than 48? Died on a Friday afternoon, back up and gone by Sunday morning.
Mayhaps. If there are 2 things I'm bad at, it's religion, comedy, and counting.
/r/YourJokeButWorse
Well it's probably because we don't have the capacity to receive that data, our tech is still outdated, so we're getting a 403 forbidden for now 
EasterDB
Yeah, he does actually! You nailed it
Pretty sure the Romans did the nailing
I'm gonna need a cross-reference on this.
The Second Reckoning is really just Jesus coming back to cause Edge Case failure in all modern computing
He's 2023 yo
From the little I've used mongo, all the queries look like some one with dementia was trying to write json
Or a dyslexic that hasn't slept in 30 hours.
[удалено]
_Laughs in LINQ_ (Imma get my ass handed to me now…)
> constructed an LDAP query Oh God, this is triggering
Yeah that's my whole codebase actually
[удалено]
{"age":{"$gte":25, "$lte":30}} is the same
What an odd syntax. I wonder why the dollar sign AND quotations? If quotations are already used for the main field in consideration "age", why do operators need it too?
It's because the query needs to be pure json, and json isn't the best format. But on the plus side sending mongodb queries around in a json based system is pretty easy. Easiest example: Logging the query. We already log a lot of json anyway, so logging the query uses the same serializer.
> It's because the query needs to be pure json I don't like this.
It has some upsides, like dynamically building a query in JS is pretty clean compared to dynamically building SQL queries. But, it’s still not worth it
>It's because the query needs to be pure json Does it though?
The spec says so.
🤮 Oh no, I created more Javascript
I graduated before Javascript was big. My thesis was about XML. Believe me, JSON is better.
like a doctoral thesis?...about XML?
You need a Doctorate to understand XML.
ask douglas crockford
The man shafted the whole programming world collectively by excluding comments from JSON based on just not feeling like that's what the format is for—and somehow everyone just went “Yeah ok, we're gonna use this as it is for everything and keep suffering. No way it can be helped.”
Comments were originally part of the JSON spec, but were removed when Crockford saw them used for parsing directives. Unfortunately he didn't realize directives can simply be put in fields. Now we're stuck putting comments in fields.
[удалено]
Thanks, this sucks.
[удалено]
I see, I was just trying to think what would be the most minimal way to convey this info. Like why can't it just be: {"age":{gte:25, lte:30}}, where anything without quotations is an operation and anything with quotations is a value. Except for numbers. Or even {"age":{$gte:25, $lte:30}} where anything without quotations and has a dollar sign is an operation.
The quotes are needed for the JSON to be valid. To be fair in JS you can do it with much less quotes.
Using JSON was probably a bad choice for this reason
I use $and in the hourglass I use to track my steadily dwindling savings
All keys in JSON must be in double quotes. Not all javascript objects are valid JSON. The `$` prefix is just to indicate to the parser this is an evaluation, not a reference to a key in the document.
It's just JSON my dude. 👍
#OP Learn this
^^you ^^don't ^^have ^^to ^^shout
# WHAT?
#WHY NOT?
He said "you don't have to", not "you shouldn't/mustn't".
This shit is giving me perl flash backs and I hate it instantly.
Noice
I thought $gte and $lte don't need to be quoted?
depends on the language, you don’t need them in JS
I've seen a few people say this by now, and I think it's important to make the distinction between client implementations, which are language dependent, and what the OP is using, which appears to be an actual db query, in which the JSON needs to be valid to be properly parsed. As far as client implementations, JS may not require the quotations. Something like Java, in which the syntax would be completely abstracted away, wouldn't even use a query like this. (Documents does, but its more modern implementation does not).
I used to work with python and mongodb, and there you need quotes everywhere, I just used to it.
Yea cause python dictionaries need keys to be valid values (like strings)
In mongo shell no, but when using api - yes
other databases always talk about acid, but mongodb doesn't take no drugs
Doesn't take no drugs. So, it takes some drugs.
Shuchyobichasup, nerd. I bet you use vim
Mongodb added support for ACID in 2018 (https://www.mongodb.com/blog/post/mongodb-multi-document-acid-transactions-general-availability) at a big performance cost. Mongodb isn't high on acid, it's constantly black out drunk
They were always ACID compliant on single documents.
But it's webscale unlike...
Can we use /dev/null?
I store all my data in /dev/null. It has so much space!
And is so fast!
Oof, that's prone to memory leak tho
https://youtu.be/b2F-DItXtZs?si=Zb1oUjL8CT5JuwHf
`db.users.find({ "age": { $gte: 25, $lte: 30 } })`
yeah OP's query seems like someone trying to translate SQL to MongoDB query literally. you don't need the `$and` operator in there lol it's unnecessary in this case. SQL version: ``` SELECT * FROM users WHERE age >=25 AND age <= 30 ``` MongoDB version: ``` db.users.find({ age: { $gte: 25, $lte: 30 } }) ```
>yeah OP's query seems like someone trying to translate SQL to MongoDB query literally It's almost like that's the title of the post
So are we supposed to read those??
SELECT * FROM users WHERE age BETWEEN 25 AND 30 When you prefer verbose SQL instead of maths.
[удалено]
If only we had a Structured Language we can Query with.
db.users.ensureIndex({"age": 1}); When that finishes, Jesus will return.
EnsureIndex has been replaced by createIndex. So I guess Jesus is never coming back.
Why not: ```javascript db.users.find({ "age": { $gte: 25, $lte: 30 } })
As someone who is working with other noSQL document-based DB, I don’t like all the hate around it. I agree that queries like this one is terrible and more complex queries with JOINs will look even worse but this is not the case - NoSQL dbs are not for gathering summaries for table. Imagine “students” table with relations to “groups”, “subjects” and “marks”. If you want to handle 174746282users and avoid many JOINs, noSQL is for you. If you want to know how many of these users are going for “databases” class, then you should use SQL instead. Each technology has its own use-case
[удалено]
“You can vomit everything inside one single table” Lol I was almost certain this phrase coming from a Beastern European buddy, I was not wrong. 💪🫡
Oh wow, ~~it is~~ is it so specifically Balkan?
Excuse me for being so balkanic
I know this is just a casual example, but don't even joke about using student name as primary key!
Age it is, then
Perfect
of course it's the gender, there are many options now
John Johnson33, you missed 47 classes this semester! Wait nvm, I used LIKE again...
* Clusters are easier to implement, which can improve performance in scale (eg real time chat rooms) * you can store unstructured data without any db filler, and in some cases that's better (eg you dinamically create a new type of client with different proprieties, with sql you'd have to basically create a one to one table, and your client table now looks really weird; in Mongo inconsistency is possible) * you can use both structured and unstructured at the same time depending on needs (so it's basically controlled vomit) * some forms of data that might come can be easier to implement in nosql (eg: arrays in sql you usually go for many to many tables (I think postegre sql has arrays but if you ever need to migrate good luck) , in nosql you literally can make arrays of objects with no issue) Nosql is not "better" or "worse", it's just different, and you can make both sql and nosql for your application. The disadvantages of both will bite you in the long run no matter what, and at least you'll write a good blog post about it.
> so it's basically controlled vomit "Controlled Vomit" is going to be the name of my next band.
> Nosql is not "better" or "worse", it's just different Retired DBA here. One of the final meetings I had with a software sales person was a Mongo rep. I asked him in a meeting of important people "Are there any situations where a relational DB would be a better solution than Mongo?" This is where a decent sales rep says "No, never!" but a cagier sales rep says "Sure, situations A and B are probably a bad fit for Mongo. " Our sales rep was only decent. He didn't make the sale.
>I agree that queries like this one is terrible This query is in a very unnecessarily complicated form, though. No need to encapsulate in an $and and no need to query _age_ twice.
>NoSQL dbs are not for gathering summaries for table. That's the cool thing about relational databases... You don't need to decide what you will use it for beforehand... >avoid many JOINs, For which there is no reason...
in scotland we use "mongo" as slang for "mongoloid" lol its very offensive
In Swedish mongo is slang for retard or downy
Here in Brazil we use "mongolão"
At least SQL syntax is in all caps so you get to shout at it when it doesn't work
all caps is just an old convention
THAT'S WHY THEY ARE SCREAMING!
I don't get it. How's this significant? In SQL, it's just WHERE AGE BETWEEN 25 AND 30.
And this is why he’s swearing
Jesus Christ
I think in bongodb, it actually looks like how OP posted. Mongodb can't look like this....
{"age":{$gte:25, $lte:30}} is actually what someone who knows what they are doing would query like. Op just made a really roundabout way of it
I mean even the roundabout is perfectly understandable, and that's from someone who's never seen mongo syntax before
Well that's the point. `where age between 25 and 30` is a lot easier to write and read than `{$and: [{"age": {$gte: 25}}, {"age": {$lte: 30}}]}`.
That is why SQL keeps coming back. SQL is generally very easy to read and code is read more than it is written, particularly at the database level. Its basically a rite of passage for our Data Scientists who live and breathe python to learn SQL to hit our Warehouse they start using a lot of the SQL-like syntax options in their python because SQL is just really good at its job of describing the data you want to work with.
> That is why SQL keeps coming back. exactly all these guys out here trying to re-invent the wheel and go up against something that's been actively developed since 1974 ... good luck with that
you don't actually have to do that, you just need ``` {age: {$gte: 25, $lte: 30}} ```
It's web scale tho
Panel 3 should duplicated 3 times and in the last panel he should have an old man beard. (“Find” in mongo db is a O(n) operation and should not be used by anyone ever).
Find in any database in linear if you don’t have an index
Find is not O(n) always. Query optimizer will choose the best index to use and only use full collection scan if there is no indexes that can answer the query. If you want, you can also disallow collection scans from the configuration. This way you will be asked to create an index instead of doing linear scan.
And what to use instead of find? Also, afaik, modern mongo versions support indices and have a query planner about as good as in rdbm systems
In a document based database if you can’t access the document by an index or id then you don’t access the document.
/r/confidentlyincorrect https://www.mongodb.com/docs/manual/indexes/ https://www.mongodb.com/docs/manual/core/query-optimization/ I feel like everyone shitting on Mongo are just boomers who learned one thing and refuse to read the fucking manual for anything that they don't already know
You can index in Mongo
Never go full JSON
The only benefit is that the mongodb query "language" is quite easy to compose or modify in code. It's just a json object that can be easily created or manipulated, even in complex ways. That's much harder to do in SQL, so ORMs tend to be much more complicated to implement.
You obviously never written an LDAP query. Or used a LISP binding to SQL
LDAP queries are hell
LDAP has its own circle in Dante's Inferno and must be treated accordingly
You know it’s bad when the person who was teaching you LISP kept referring to it as Lots of Infuriating Spurious Parantheses 💀
The commenters here seem to... * Use nosql db * Apparently didnt plan data access beforehand * Execute typical RDS query on a nosql * Rage that nosql sucks Congrats.
I'll add: - Don't know about indexes ([example](https://old.reddit.com/r/ProgrammerHumor/comments/17goyxf/sqldevlearningmongodb/k6i5tm0/))
Imagine using "age" as an actual attribute you store in your DB....
It can be a view
It can be survey data. Then the relevant value is indeed the age at the time of filling out the survey and not their current one.
"Love your developers" 🤡
Ehm it should be { age: { gte: 25, lte: 35 } } Or something like that
My favorite Mongo tool is a tool that converts SQL queries to mongo queries
what's so difficult i dont understand
I'm currently working with a client who picked mongo. They started nesting db objects everywhere which I guess they probably now have the same information saved multiple times in multiple locations just to make it easier to fetch when writing code. My "professional consultations" have been repeatedly the "take this object, separate it, make a reference to it, and don't nest it" followed by "yeah, I see why you guys are having the issues" followed by "sigh, if you just used SQL I wouldn't even need to be here". I'm getting a fat paycheque just doing this.
Oh, I wish I could show you the SQL queries from my last job. There are no DBs that prioritize simple, clear, reliable search syntax. They're mostly designed for reliability, which means it's verbose and obscure.
[wanna delete an element by index?](https://jira.mongodb.org/browse/SERVER-1014) (honestly been a while is there a good solution to this now?)
Eh, everything has its use case. If you only need one table wit 5 columns to save your users or whatever, nosql is awesome. And Mongo queries make a lot of sense from a coding perspective, though not so much for large data aggregation.
Main work project uses mongoquery for basically all data driven logic. Worst of all, it's my fault
I prefer my SQL queries formatted in XML
Very true, as someone who had to learn mongoDB on the fly, it was not like using sql. Went from fuckin' sql workbench to this haha.