Jesus died at 33, so that can’t get returned in the query response lol
SELECT user FROM db WHERE age BETWEEN 25 AND 35;
Fuck your mongo
Mongo only pawn in scheme of life.
deleted by creator
I DO NOT SEE ANYTHING WRONG WITH THE PREVIOUS COMMENT, JUST A NORMAL HUMAN TALKING LIKE ME.
We just got a ticket in, our users need several new fields in the user table
Relational virgin:
NNNNNOOOOOO I’ll need this sprint to modify the user table and write the etl script
NoSQL Chad:
private String newField1;
private boolean newField2;
private Object newField3;
//And now, I close the ticket and go get lunch beers.
You do know that a large majority of SQL flavours support JSON columns?
All this talk about query format and no one discussing the dogshit database design requiring the record to be updated whenever the user has a birthday? Store the day of birth and do the math at query time at least!
Does mongodb have virtual columns?
deleted by creator
I’m no mongo fan, but this is ragebait.
You can write it like this, but you can also write {age: {$gte: 25, $lt: 30}}
If you’re going to dunk on mongo, let’s talk about how db.collection.update() replaces the whole record by default instead of updating keys
Thanks for letting me know that if I’m ever asked if I’m willing to learn mongo the answer is no.
I do believe Mongo has some valid niche use cases, but far, far too many people think it’s just a no-worries way to dump objects into a database without having to deal with all that fussy schema stuff. They only realize their mistake when it comes time to actually use that data as anything other than a huge, unmanageable blob of nested fields.
Granted, Mongo’s marketing kind of encourages this.
Slightly off-topic: I get so confused with age conventions. I’m self-taught and do some ad-hoc work for the organization I work for (where no one else has any interest).
To get users between 25 and 30, wouldn’t you want strictly less than 30? And greater than or equal to 25? Or for age is it inclusive?
Realistically you wouldn’t store age, you’d store birthdate or possibly a datetime value, and calculate it from there
First Normal Form users unite!
By the by, as someone who have used both NoSQL and SQL extensively (once in the same project), the trick of NoSQL is that you shouldn’t use FNF and compute that at write time. The idea is that it’s faster to MapReduce pre calculated values since that’s the operation you want to optimize in a NoSQL world. A lot of people get that wrong and just replace MySQL with Mongo without rethinking usage and schemas.
But even in a NoSQL context I’d rather use a Postgres jsonb column over MongoDB.
This is a question for story refinement.
Why strictly less than 30 and greater or equal 25? (25 ≤ X < 30)
Shouldnt it be strictly less and strictly more (25 < X < 30)?
And here comes the most annoying error, the off by one error
I guess you could argue that people we refer to as “25 years old” are actually 25 years and some days/hours/minutes/whatever old, therefore more than 25. People referred to as 30 are, in the same vein, more than 30
Well if you’re 25 and a day, that would mean you wouldn’t be able to fit any definition. The second after you turn 25 you would be “over 25” and could be included in 25, over 25 and between 25 and X until you turn 26 and the same repeats.
Even if you’re 25 and 11 months, you should still be counted as 25. Same way it should be for other age based restrictions
But you’re not 25, you’re 25 and 11 months you can’t have your cake and eat it too.
If it’s the same way for other age base restrictions, you are now contradicting your original comments point… it’s between 25 to 30, so 25, 25 and a day, and 25 and 364 days would all be included.
Unrelated question but why can’t one have a cake and eat it? Presumably that’s why you’d own a cake in the first place. Or is world filled with people eating other people’s cakes but no owner is ever allowed to. Such a mysterious saying…
The easiest way to parse the meaning is to reverse the statement order, i.e. “Can’t eat your cake and have it too.” If you ate it, you wouldn’t have it. If you have it, you haven’t eaten it. The two states are mutually exclusive.
Okay, that makes sense, just weird choice of words.
I’m an adult and go just drive and buy a cake anytime I want. I think it comes from you buy a cake to share, you are supposed to buy “a slice/piece” for yourself?
I don’t know but it doesn’t make sense. The saying, that is.
That phrase is about fancy cakes, like wedding cake art. You can’t keep the art and eat the cake. Like the food network cake competitions, some of those things are super creative, but you can’t have the art and eat the cake.
It’s like painting custom wrapping paper, or printing on toilet paper. If the purpose of something is to be consumed or destroyed, it can’t do that and look good at the same time. You have to choose between having pretty mocha art and drinking a mocha.
I’m not contradicting anything. I think someone who’s 25 years and 11 months should not be returned from the query. Hence, the strict inequality
But you absolutely are contradicting yourself……
they are between the ages of 25 and 30 meaning your information would be incorrect or wrong… and it’s not even a debate since they are in fact between he age range.
It’s like saying 25.2 isn’t part of 25, and that’s not up for debate, and if it is well you’re not here to discuss in good faith now are you?
Okay, since you’re starting to throw insults via this angle, let’s try to make my case via a different route
Do you think the db is storing your age as an int or as a float? We know from the given information that it is stored as a singular number
So, I’m assuming it’s as an int, which means that until you’re 26, you’re still 25. If you’re 25 and 11 months, that’s still 25 years old, and stored as such. The strict inequality should therefore not put it in the range 25 < X < 30
deleted by creator
“Between 25 and 30” would tell me 25 birthday (since even at 12:00:01 you are over 25 by a second) to one second before 30th birthday.
So ages 25, 26, 27, 28, and 29.
I’m going to laugh at this all day
THIS IS WHY YOU NEVER WRITE YOUR ENTIRE QUERY IN A SINGLE LINE
deleted by creator
As a c# mssql developer I’m not familiar with json or mongodb but I don’t get the meme. What’s wrong with this syntax? It’s readable and relatively concise. Is this a whoosh moment for me? What am I missing?
It’s a mess compared to the equivalent SQL.
SELECT * FROM users WHERE age >= 25 AND age <= 30I dislike SQL syntax more than most, and even I concede that SQL wins in this instance.
Edit: Not sure if this appears on all clients but the < in the code block is meant to be a less-than symbol.
There is no way I would ever get the amount of brackets right on that.
IMO it’s just so clunky with what feels like way too many extraneous symbols. And that’s just a very simple query, check out the equivalent of a join: https://stackoverflow.com/a/43653679
Granted, joining is not really what Mongo DB is for (that’s the whole point of it being non-relational, after all). But even reaching deep into an object can get you into nesting hell very quickly.
I’m unfamiliar with the last comic where Jesus Christ is said. Does it mean he is happy with the result or can’t bear to look at the result?
The OG comic was a guy talking to a baby, saying “Hey little guy, how’s it going?” and the baby replies with gibberish. The third panel indicates a pause, and then the guy responds in the fourth panel with “yea” (which is supposed to be “yeah” and not the archaic affirmation that rhymes with “nay”). It’s like he doesn’t even know what he expected when he asked the question, and is just accepting the awkwardness and confusion.
The “Jesus Christ” variant seems to imply the stunning horror of whatever the guy sees in the second panel.
He is horrified
The latter, although it wasn’t originally like that
MONGO!
