Please kill me

>it there a better solution?
Various "NoSQL" databases are often a better solution.

You can pick one with either better data constructs to natively use with your language of choice (SQL is pretty much always behind a translation layer of sorts, because it's SQL), and/or one whose performance trade-offs match more what you need (often less important for "average" applications, but maybe you're doing more than that?).

If you understand SQLite then setting up and managing a PostgreSQL server, if needed, isn't a big deal.

is this shit better or worse than mysql?

>Various "NoSQL" databases are often a better solution.
Various "NoSQL" databases are rarely even an acceptable solution. Every large-scale service out there doing something even remotely important is running on a relational database.

You should use MySQL.

Attached: MonkeyBoy.png (498x660, 355K)

Substantially better. MySQL is shit without a bunch of Percona add-ons, just to be able to function. MySQL is probably the second worst thing you could possibly pick as your database, besides something like MongoDB.

>Every large-scale service out there doing something even remotely important is running on a relational database.
Completely wrong? Almost every large scale service on the internet is NOT running on SQL.

That is all the social networks, search engines and so on. Netflix and friends (last time I checked they were using Cassandra). Pretty much whatever other really big thing you can think of.

What's needed is a robust form of logical replication between SQLite databases and a PostgreSQL DBMS.

>So close but Hipp missed it.
youtube.com/watch?v=Jib2AmRb_rk

Its harder than mysql, but extensively more feature-rich.
Naturally brainlet webdevs hate it, but your average sysadmin/DBA can handle it fine, so its not really rocket science.
As a sysadmin, I can tell you it is pretty common for webdevs to follow mal-practices because they don't understand postgres, later we have to patch this shit from our side so everything doesn't explode in their faces.

If you include graph under the "NoSQL" umbrella, this isn't necessarily true. Although a lot of graph databases can and do actually store the data on a relational backend.

Have you tried reading some books? They mostly suck but it might help a little...

You better not be benchmarking this behind my back, goy... oy vey, remember the 6 million... dollars it costs to run this per year.

>Thinking netflix uses only cassandra and nothing else
>Thinking netflix matters anyways
Pretty much everything, from NASDAQ to Slack uses an RDBMS system for any data that matters. Using some NoSQL solution to store user bios and thumbnail images does not mean a company is putting their transactional workloads on NoSQL.

I'm not actually sure the graph parts of even Oracle, MSSQL and friends are sitting on a fully relational backend.

I think they're basically just a NoSQL addon for people already in these ecosystems.

the SQL standardized JSON type deprecated all NoSQL

I figure it might be a match for NASDAQ?
But I can't find any reference to what they're using now though.

Even so, it ought to work on SQL; for the most part this is a very easy data set. It's not like you can even directly trade gold for stocks, so the machines and queries can be separate to relatively modest tables.

> some NoSQL solution [...]
Runs Google and *many* other's main business, yes. Not thumbnails.

Who is even bigger on data than Google anyhow?

>So close but Hipp missed it.
What?

>imagine being too retarded to use a difficult to reason about declarative language with wildly different implementations and performance edge cases.

I know right?

I agree with this. Came from MySQL, started using PostgreSQL. Much prefer PostgreSQL from a feature-completeness point of view.
MySQL's JSON support is poor.
I've never benchmarked the two though and would be interested in which one performs better.

by the time you realize what a huge fucking mistake your document/key-value store is it's too late

What's the alternative? Also, the wildly different implementations don't matter. Actual code is always written against a particular database, not SQL databases in general. A decent planner should be able to explain your queries performance to you.

Richard Hipp describes an important use-case/architecture in that video but he missed/overlooked the [seemingly obvious] opportunity/need for logical replication mechanisms between the central database (PostgreSQL) and the local application database (SQLite).

>Almost every large scale service on the internet is NOT running on SQL.
Because the web industry is where decisions are usually made by trendy hipsters and not competent engineers.
SQL itself has never been that bad, as far as mainstream languages go it's pretty decent. People were desperate to get away from it it because they thought they hated the language itself when in reality they just hated the shitty garbage ENTURPRIZE software that happens to use it.

>MySQL's JSON support is poor.
What the fuck do you even need this bullshit for? You god damn fucking faggot blue haired neutered freaks.

Jesus Christ you guys are such cancer. It makes me livid.

99% of web sites can run stock SQL, what google and AWS do is not typical

MSSQL's XML support is sucky sucky suck suck.

Yet, even the free version comes with virtually everything I need.

SQLite is all you need most of the time.

SQLite is comfy.
Plus, instead of a license it has a Christian blessing.
And instead of a cucked code of conduct it has a code of ethics based on the Rule of Saint Benedict
sqlite.org/codeofethics.html

True. Most dbs, even sqlite3, usually give ok information about your query if you ask. Overall the experience is lackluster though. I'm not sure what the alternative is.

I don't have anything against relational databases, just SQL as a language to leverage this database type.

mysql has a bunch of design flaws related to null type

>Relieve the poor.
>Be not proud.
>When wrongful thoughts come into your heart, dash them against Christ immediately.
>Disclose wrongful thoughts to your spiritual mentor.
>Hate no one.
this is the most cucked thing i have ever read

Imagine being bad at tables. Absolute nodejs shitter

imagine using relational dbs to deal with data structures that can change every two months

i-it's webscale bro, so dynamic~

Attached: 1552663192495.jpg (960x492, 56K)

45 minutes of boilerplate before he gets to the novel idea of this talk.

I use it on my asp.net core program. Shit is very portable. Ultimate comfyness. But shame it can't handle big traffic though.

Flat files is an alternative

But not a smart one.

Let me guess, the biggest issue is that real SQL skills don't translate to Postgres because of the backslash windows bullshit that it represents?
\d
\dt
etc ?

That was my biggest stumbling block but you need to just accept it as part of life when dealing with postgres. It's better than trying to install MySQL 8. imo.

Just learn it dawg. Read the docs and suffer. You'll be better for it.

>MySql
Why not MariaDB? What's the difference?

>99% of web sites can run stock SQL
95% of web sites can run on Hipp's WAPP and SQLite.

>instead
Nah-ah. The corporate sponsors made the adopt Mozilla's Participation Guidelines.
sqlite.org/codeofconduct.html

Ghetto skank nonsense.

Oralkill.

Everyone knows MS SQL is the true endgame

>MySQL's JSON support is poor.
This isn't 2010 senpai

I see you've never worked with both.
Seriously, the difference between \d and DESCRIBE TABLE is lost on you???

There is a clear difference in there.

The difference is what your ERP requirements are... If you're too young to realize this that's fine but let's be honest, postgres is a more mature DB than MySQL without a DBA,

last post of the night:
MySQL is just as bad about so much shit, but you should see that there's no "clear right answer" to a relational DB.

Maybe the people on this board are beyond me but I really don't understand choosing the "community savior" vs choosing the "accepted best practices" of postgres,

t. I've been dealing with this shit for 5+ years as a "backend" developer.

Just pick whatever works for your company and move forward with it. Upfront cost is limited by developers that need to acquire skills rather than developers that "know what's right".

best and cheers.

Why are there so many different versions and differing opinions about a family of software that is essentially a glorified collection of spreadsheets?
I understand SQLite because it is based on a simple file structure per db, but the others are all essentially just software that responds to a bunch of SELECT * WHERE etc. commands, right? How can that spawn a discussion as extensive as this thread? Is it just the commands they use to run the same queries? Their performance on larger datasets?
Genuinely curious here.

Attached: 1ridfdjw48o11.jpg (700x919, 95K)

Postgres' only downside is that it isn't GPL.

It's license isn't GPL specifically but its license is open source and GPL compliant.

From just running SQL queries there isn't a whole lot of difference between the different RDMS as long as they comply with some SQL standard. The differences usually start popping up when it comes to things like performance, backup / replication, data types, access control, and extended features. This is where the different RDMS start to distinguish themselves.

>imagine using relational dbs to deal with data structures that can change every two months
Adults don't keep changing their schemas every two months.
If it's good enough for airlines, stock exchanges and banks it's probably good enough for your pet food delivery startup, nigger.

Attached: postmodern databases.png (1153x997, 1.6M)

How exactly is it a downside?
I don't understand the GPL trolls on this board.
To start with, GPL doesn't prevent companies like AWS to take your code and make millions with it while giving you peanuts.
Even before that, if you write GPL code you're still making money for Red Hat, SUSE, IBM, Oracle, Microsoft, etc.

It's also the case with BSD licenses, yes, but it's not exactly worse.