2016

>2016
>using sql

Other urls found in this thread:

engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.1kb7gic6u
youtube.com/watch?v=b2F-DItXtZs
sqlite.org/whentouse.html
twitter.com/AnonBabble

I use SQLite a lot, because I work in the embedded industry.

Fuck you and your meme web crap.

>traversing the index's entire b-tree to provide a count on a constraint

But Mongo is webscale

>tfw even postgresql is faster for NoSQL functionality than NoSQL databases
lmaoing @ ur life OP

Why is it always that SQLfags always attack the worst modern database when they try to defend SQL? I don't see NoSQLers attacking MS Access and calling SQL bad only because the faults of that.

>mongodb.png

>mongodb.png

the engine in access is actually the same as in MSSQL and its fucking great.
Access has limitations due to it being serverless tho

>using an object based database
Try using it for financial transactions. Your startup will tank within the month.

Modern databases are the equivalent of some twat creating a gear and claiming that it also makes a better wheel. Sure it works in your use case, it does not replace the traditional database though.

nosql is a dumb umbrella term designed specifically to advertise broken buggy databases (like mongo). If you needed something that postgres couldn't offer you you'd be able to name it specifically., and there's all sorts of things that could be, but "you don't have to use this specific query language" probably isn't it.

SQLite doesn't share those limitations

It's probably just arbitrarily limited so M$ can jew out more money

MSSQL a shit. The only acceptable rdbms' are SQLite if its all you need, MySQL and postgresql if you want more functionality

MySQL is legacy

Postgres is much better

engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.1kb7gic6u
>using mongoDB

you would be sadly surprised at how many large companies have bought into the nosql meme for things like that

mysql and mongo are equally bad ideas in their respective domain

lol i remember this one. absolutely shameful

nosql really only has use for large unstructured data.

fucking regular schlub javascript coders who think it's good have no idea what thy're doing. if you can design your database schema correctly, nosql really has a very small usecase where is actually more useful than a relational database.

the people who are championing nosql / mongo are the kind kind of people that php was built for. fucking non coder normies who have no idea what they're actually doing.

Isn't it better to use mariadb instead od mysql these days?

>Using an unstructured solution for structured data

Care to explain? (no trolling, just asking)

use postgres for everything unless you have a specific reason not to. "it doesn't work with my javascript framework out of the box" is not a reason

Tbh I use whatever im told to by whatever app im deploying. Being an autist and being diehard in favour of one fucks you up

test post

Do you frequently need to use JOINS?

>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

an extremely bad track record for quality engineering and design choices, both of which you really want your db to have. google "mongodb data loss", the billions of articles out there explain mongo's history better than i could.

it's also kind of a pain on the ops end. you can't just restore old/add new nodes to the cluster, you have to bring back an exact copy that crashed from an _os snapshot_, not even mongodb's backup tools, and it has to have the same id.

>mongo lDB

Yes but it is webscale

not even the worst of it. see . hope you enjoy explaining to the rest of the company why those financial reports randomly have missing customers, but if you use mongo, you're probably enough of a drooling retard they'd excuse it on you entering result sets into excel by hand

The name sounds like a nigger.

>implying shitloads of data haven't been lost from traditional SQL databases because of shitty programming, bugs, bad hardware, disgruntled dbas, etc

>ou have to bring back an exact copy that crashed from an _os snapshot_
you should be running your shit in a cloneable VM anyway, sounds like the problem is with you user

FUCK Mongo. Stupid thing corrupts itself all the time and our development team can't be assed to replace it with PostgreSQL for critical customer data. I spend way too much time manually repairing broken tables from the mongo cli.

You can use something better than Mongo of course. It isn't a dichotomy between SQL and Mongo.

>mongodb keeps me employed
>I really wish it didn't
explain

ok, relational databases are based on the idea of your database always being in "valid" or "correct" state, basically it follows the idea that your database transactions move the databse from one valid state to another. or when they fail they revert to the last "correct" state. There are other things but the general principal is called "ACID". Which means that any operation you perform on the database is going to be the "most current and correct" version of the data.

nosql databases by design do not follow this "ACID" principle. They follow a concept of "eventual consistency" that is they're designed to get the data out as quickly as possible. and in the background changes eventually propagate between to be "consistent". This is fine if all you care about is serving data, but there are problems, .A system can fetch what it thinks is corrrect data, but in reality it's "stale", becuase there has been another transaction on that same data. The problem with this, is that it applies to both read and writes to your database, which means you can lose valid transactions on your database. which is a prety bad thing.

I'm sure you can see why "eventual consistency" while good for lets say serving out craigslist posts is handy, becuase you only care about "serving" that post to a user, is a very bad idea for anything that has sensitive data requirements. Financial systems being an obvious scenario.

>tfw work uses postgresql for their biggest project, which I don't work on, and people like me are stuck with projects that use MySQL
FML, all the shit that's easily done with hstore fields in postgres, but I gotta compromise with either a new table, or some hackey comma-separated textfield in MySQL

youtube.com/watch?v=b2F-DItXtZs
It never gets old.

>>implying shitloads of data haven't been lost from traditional SQL databases because of shitty programming, bugs, bad hardware, disgruntled dbas, etc
that's not a reason to use a worse system with a proven terrible track record.

>>ou have to bring back an exact copy that crashed from an _os snapshot_
>you should be running your shit in a cloneable VM anyway, sounds like the problem is with you user
that's still more work than necessary. it's a less flexible, more fragile system

yeah, there are good nosql dbs. just not mongo.

Fixing Mongo problems is stupid busywork that delays the actual main reason I have a job. It's like when your teacher assigned you word searches as a kid because ayy lmao.

you don't climb your way up the ladder by spending all of your time doing maintenance on a shitty product.

It's extra fun when the system with Mongo problems IS the backup server.

every database in existence has a terrible track record because of shit sysadmins like you, again PEBKAC

>that's still more work than necessary
oh no, you have to do actual work to manage your own fucking servers in a reproducible way

> it's a less flexible, more fragile system
no it isn't, fucking learn how to do your goddamn job, the only "inflexible" thing here is you if you can't figure out how to back up a fucking VM

>database is so fragile it needs to run in a frequently snapshotted VM
>this is the admin's fault somehow
Mongo fanboys, everyone.

>every database in existence has a terrible track record because of shit sysadmins like you, again PEBKAC
again, DBAs being dumbasses is not an excuse to use a terrible database on purpose

>oh no, you have to do actual work to manage your own fucking servers in a reproducible way
>no it isn't, fucking learn how to do your goddamn job, the only "inflexible" thing here is you if you can't figure out how to back up a fucking VM
good products do not make simple things complicated unless there is a reason. mongodb's reason: they blow their VC money on marketing instead of engineering. other major nosql databases do not have these issues

Why no one ever talks about google's datastore? Is it that bad? Worse than mongo?

It's Google hosted. Assume it's being data mined constantly.

because i don't work there, and cloud vendor lock-in is bad

did you expect to get webscale for free?

What are you talking about.
Installing mongodb will automatically gives you webscale.
Not other solution scale like mongodb.

/s

Only a true code artisan can properly cast such powerful spells as mongodb

>2016
>not using the right parts of CAP theorem

Im a newfag when it comes to different SQL implementations.

Can someone tell me what the differences are?

Ive been using SQLite, and dont really see any reason to use anything else

>limit on number of indexes per collection
>entry overhead of 48 bytes
>100% memory usage because devs don't understand how mmf works
>no custom indexing functions
>MySQL tier update speeds
>limited binary type bit operation support
>drivers even AMD wouldn't approve of
>all data is relational, storing it as objects is inefficient and just stupid
basically perfect for web devs who have nfi how anything works.

postgres or go home.

Thanks for using YOUR data to prove databases shouldn't be fucked with.

wasn't this depreciated since like day 1? there is literally no situation where it's better than existing solutions.. infact it's worse in almost all situations :|

ITT: SQLfaggots defending their depreciated shit database

what do you use then?

Nothing really, just Sup Forums being autists

sqlite.org/whentouse.html

readonly then it doesn't matter
writing to your database for multi users is problematic since writing locks your file.

Why is everything I learn in school shit on on Sup Forums?

Learn C - "C is shit"
Learn Java - "lol, OOP. Java is pajeet shit"
Learn SQL - "SQL is shit"
Learn UML - "Nobody uses UML outside of university"
Learn Agile - "Agile is shit"

>Listening to Sup Forums
There is your problem

Only if you use the deferred write of Mongo, which, as you said, will update the data "when it's less busy". You can turn that off by forcing the data to be updated when you submit it (turn write concerns on) but then you lose a lot of the speed of Mongo.

Nobody on Sup Forums has a job.