The Stockholm Syndrome of SQL | Prime Reacts
Вставка
- Опубліковано 26 вер 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Article: southcla.ws/sql
By: Barnaby Keene | / southclaws
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-K...
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...
Did you know that the technique for making bricks used today predates the epic of Gilgamesh? Sometimes things not changing is OK.
Sql has some unfortunate issues that bricks don't though ;)
Do you mean data bricks or brick bricks?
The thing with SQL is based on the relational model for databases by the legend Edgar F. Codd. TLDR it has a tons of math to back it up, not just hype.
Codd himself would disagree with that statement, and indeed does vociferously in "The Relational Model for Database Management" Version 2. (ISBN 978-0-201-14192-4)
In terms of the relational model, every query would, at the very least, need to effectively be qualified with "UNIQUE". Also, the original model had two types of NULL (missing but applicable and missing but inapplicable) - which relate to how aggregates work. There are many, many more differences between SQL and Codd's idea of a Relational Language.
I was hoping this was the angle the OP would take to disparage SQL, but was somewhat disappointed by the actual article.
CJ Date's 1983 essay "A Critique of the SQL Database Language" also goes through many of the objections, and is possibly more accessible.
@@robgrainger5314 being based on doesn't mean identity. The theoretical ideas almost always get organically adapted to reality during implementation.
If anyone still longed for two nulls and thought it was a good idea in the 80s and 90s, I think Javascript pretty much wiped all of them since then
Not every technology needs to be like JavaScript ecosystem.
It's blessed to have established, log-lived technologies like SQL, UNIX and REST in this fast-moving industry.
But then these morons have to learn things that aren't JS, and that's just too much to ask.
“Any application that can be written in JavaScript, will eventually be written in JavaScript.”
they are coming for you buddy.
you cannot stop it.
you will not stop it.
to be clear, I'm not advocating for getting *rid* of long-lived tech! that's great and needs to stay, I'm just interested in trying something new in an area that seems to have very little innovation!
@@BarnabyKeenei am not bashing you for wanting innovation, but why care about dbs of all things? Sql dbs are fundamental, solid and extremely boring structures since thats what they need to be. Feels like wanting to redo the plumbjng in an old house that was already working without any issues, it creates more problems than it solves imo
@@fullmontis i think there is plenty of room for improvement in DBs. change for the sake of change is bad, but i could see DBs improving as part of a bigger change
I'm not a developer, but work in analysis and use SQL daily. It is so useful that most databases use SQL, because otherwise I would have to learn so many languages. Even though every SQL dialect is a little bit different its close enough that hopping from MSFT SQL server, to Oracle, to Big Query to Postgresql isn't an issue. Would be a real pain if they all worked fundamentally different.
The pain is when going from Postgres to lesser SQL servers.
You keep having to remind yourself of the limitations.
there are indeed differences - sometimes very significant ones - but it's great that there will be like 80% or 90% common turf.
Getting into the world of PL/SQL or PSQL then there's all manner of divergences
@@TheSulross pl/SQL has a compatibility layer you can buy for postgres if I remember correctly.
@@magfal same can be said about Oracle. You can be a master ninja with oracle's hints and never get the same performance from any other DB, making some queries fundamentally impossible
@@NJ-wb1cz I've been challenged to solve quite a few complex problems in postgres by Oracle DBAs to see if performance can match.
I've wound up with better performance each time so far, even when one colleague limited me to the ancient 9.6 version.
Its funny to me how many people think that if a piece of technology does not constantly evolve it means its automatically worse than ecosystem that changes all the time. What if the technology that remained is simply good? If the goal has been achieved there is no need for constant changes. Not everything needs to be javascript where new "better" ways to do thing are invented (or reinvented) every few months.
yep. i think it's okay to reinvent the wheel every so often, but i hate it when so many other things get worse in the new way of doing things (regressions). i think it's partially because of the way humans developed software (fragmentation & NIH)
It’s not a free market unless the new thing I like is at the forefront…
I think the argument was not that SQL is bad but that we don't even try to see if we can find something else that's good or at least decent. A bit like haskel. No one says "C-based languages are nice, but Haskell is way better for production", but Haskell still exists. What they want is not for something to replace SQL, is for the option to exist, because that'd mean people actually tried and SQL is still the better option.
What makes SQL so prevalent is it's closeness to the mathematical branch that originated it. Relational algebra was first developed through mathematical tools, then converted into routines. Not the other way around. In maths when something is proven it's permanent, many of the problems relational algebra solved were demostrated to be optimal, what exactly is there improve? Calculus was invented 400 years ago, why isnt him bitching about it too?
@@Michallote By that logic, Raku is perfect. Languages are meant to be opiniated abstractions. That guy doesn't want to replace SQL, he wants there to be options.
I mean, all browser use HTML. That isn't very diverse either, right?
And it's well more smeIIy of a UA-cam fire!
Totally right. Html CSS and js
In 1998 (I believe - may be off by a year), at WWDC, there was a Q&A session. A woman asked Steve Jobs what happened to "think different" because he announced that they'd be adopting some standard thing instead of continuing use of an obscure proprietary thing (forget what the thing was). The woman named a few things the Apple thing did better than the standard thing. And Steve Jobs replied "There's probably plenty of things that does better and some things does better. But the point of Think Different was never to be different for the sake of it. The point is to be better. You can't be better by being the same, but if the standard thing is the best you shouldn't cling to being different for the sake of it. Keep to the goal; Being better. And when you're not the best, it's probably better to be compatible with what's already there and improve it from there" (very paraphrased. Been many years since I heard it from his mouth)
Also "Bad artists copy, good artists steal" etc.
I think the main reason we think highly of Steve Jobs is because he died before we really knew him. Imagine if Musk died a few years ago - we would remember him as one of the greatest humans who ever lived, despite him being the same person he is today.
Steve Jobs and Musk were good managers and had a vicious perfectionistic streak that together with luck allowed them to organize people around themselves to help others create something great, but they're still managers not creators. These quotes and phrases are quite meaningless because they don't relate to what the person was actually doing - human management and human interaction and using humans as resources to satisfy their inner imbalances. It's the sort of live love laugh nonsense your manager tells you while you're creating the product for them on your own, praying that they don't get in your way, while they're telling everyone how this is their project and how hard they are working on it
Not gonna lie, bright-eyed engineers that complain about tech choice and get mad when their preferred quirky tech isn't given the attention they think it deserves, are so difficult to work with.
I hate them they don't shut up
I was that guy in college.
Hated my db modules (oracle sql, in fairness the dinosaur prof did a bad job too)
Thought nosql was the future and preached it.
Once i got an internship and worked with production sql, i realised how much better sql is for a lot of use cases and that new and shiny isnt always better.
Then i aced another db administration focused module which used postgres because i had a much better understanding of the how's and the why's
honestly same 😂
They should probably adjust or move on but sometimes industry standards are just groupthink. React blows and is over used, even a word press site would be more appropriate at times.
I see your point, however the opposite of that is crankly old engineers doing anything to prevent fresh perspectives changing the status-quo
(coming from someone who isn't bright eyed anymore but is yet to be old and cranky, no offense to anyone :P)
This article screams to me the engineer who comes to every meeting like "GUYS DID YOU SEE THIS NEW SHINY THING THAT WE SHOULD IMPLEMENT!" Worked with a couple of those guys and it always make for unsustainable production code. SQL is just about as straightforward as database interface as you can get. You wanna create some new interface that can do everything SQL can do, go ahead.
I mean… SQL is essentially a superset of a field of math… the only way to compete with SQL is to make an entire field of math to compete with relational algebra and then make a query language to interface with data using that new math
IMO where the competition lies is in making a DBMS that better optimizes and runs existing SQL queries
I just started studying about rdbms and all I learnt for 3 days is maths.
Relational Algebra and function dependency. I did also learn SQL but I mostly skipped since i already knew SQL. But it was a pleasant experience learning the maths behind it.
@@pianissimo7121can you link any sources that you used?
Except SQL is a bad adaptation of that field of math, that loses many of the properties that make it so useful
Ten minutes in and I am still shouting at the screen that there are a whole class on databases literally called NoSQL, and losing my mind that MongoDB was even casually mentioned without that coming up
Any sufficiently complicated NoSQL database contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of SQL.
Totally right. And most people that use them impose a relational-style schema with their 'driver' ORM, for example mongoose
Primeagen's pronounciation of SQL will never not trigger me lmao
Ikr, I genuinely hate it but find it funny at the same time
Does it make you squeal?
It seemed weird at first but these days it's the only acceptable pronunciation
I know. I’m both triggered and find myself using it. It’s just too funny to not.
Haha the same! Though to be fair calling it "sequel" it triggering me just as much --it has to be specifically "Ess Queue Ell" to feel right.
If you think of databases as APIs using their own format (SQL instead of JSON), many of the problems magically disappear.
The thing is, we all agree JSON has some weak points. So what they'd like is just to have another API that doesn't have SQL's pain points, but maybe has some different pain points. It doesn't really matter if it's worse than SQL, it just needs to show people tried and SQL is still the better alternative. But rn you don't really have anything to compare SQL to. You have SQL, PostgreSQL which is another flavor of SQL, SQLitewhich is another flavor of SQL, Cassandra which pretends to be noSQL, but CQL is really a flavor of SQL, etc...
@@Exilum I wish JS/HTML was as well designed as SQL is, they don't make things like they did anymore.
SQL , a 4th generation language that really did what it promised.
Remember when there was this idea that you wouldn't need to know the implementation of HTML/CSS/JS to create pages, the computer would write it for you. (well, now we have GPT to copy-paste it for you from stackoverflow or something, not the same thing)
the problems are in your head
@@monad_tcp wait, didn’t you like Microsoft FronPage?? 😝
@@Pictor13 no, I was making fun of it on the other comment
SQL is not a string literal problem. Look at the bytes on the wire, they are fully typed. I.e. its a binary API. Many client libraries exist to move datatypes 1:1, with syntax to optimize for query plans.
29:02 The reason for that is actually a legal one.
SQLite wants to keep the project in the public domain which means that they need to do a lot of legal work too besides the implementation and maintenance work.
But here's the thing: Not everybody is able to put their stuff into the public domain. Heck, in some countries it's literally ONLY possible by dying and then waiting for it to run out which isn't really a nice way.
Imho Datalog (either the original or the datomic variant with the lispy syntax) is the best alternative syntax for SQL that manages to match it in expressiveness and is used by the relational database research community in papers whenever they publish on new concepts like incremental materialized views. Graph databases basically offer a weakened version of datalog with query languages like Cypher.
Datalog is nicer than SQL for CRUD operations, for queries that don't use negation, and for recursive queries. It is way less nice than the postgresql dialect when you actually need to optimize your queries and need to reason about the memory layout of your tables/indexes or the query plan that actually gets run. In many ways, datalog is to SQL what lisp is to the C family.
Yes! Datalog is super nice and expressive, though I do find the syntax a little intimidating, at least it's *actually* structured, unlike "S"QL which is based on the most unstructured language possible: English!
@@BarnabyKeene Slavic languages almost lack any word order, talk to me about unstructured English🙃
@chupasaurus
And yet are more structured by it being immediately obvious which abstract position a word has therby reducing ambiguity.
@@SystemAlchemist For example "You do smth?" and "You smth do?" are 2 different questions, totally zero ambiguity.
SQL is based on mathematics. There is no other/better way to do it for a relational database. It is a standard. Developers can use the same language on every relational database product. Moving applications from one db vendor to another doesn’t require a rewrite of all the code.
nothing is better than raw math
Although I’ve only used SQL like twice, I too see the value of standardization.
I quite like SQL. But no, the language couldve been much better. For example, declaring tables you query before the columns.
Take a look at PRQL, it's much better IMO
@@Akronymus_ I don’t understand. The “from” statement comes after the “select col1, col2, …”. Or are you making a joke? If so you should use some kind of emoji.
The only DB abstraction i need, is LINQ - essentially a typesafe-SQL, nothing more.
NB! C# compiles to WebAssembly - C# *is* web.
F# with type providers is even better.
I lived through dBase, btrieve, and even a few cobol banking databases. SQL was successful because of its compatibility and high level. A huge improvement over when the APIs was "give me the record index for this key". All in one process with so many server round trips.
I have been in several discuss about moving newer application to a non-SQL solution. One of the biggest reason to stay with SQL is the countless non software engineers (Business Analyst, Report Writers, etc) that are just not going to be cheaply (or at all) retrainable to do their work in a new non SQL environment.
My department has many consultants next to software development and we all (broadly) deal with data management in business intelligence tools. In my experience you are spot on and its the same reason Excel is still a favorite tool of choice for managing and analyzing data (to the horror of everyone interested in BI). Unless you are a huge corporation, databases need to be relatively accessible to people outside of IT and you will never come up with a system that can compete with the millions of hours of experience people have painstakingly gathered in SQL. Same goes for Excel. People working in these areas suffer from a small aneurysm if you change the UI a little, imagine what happens if you change how the formulas work they have adopted over the course of a decade.
For years some software gave you the option to select between two SQL DBs. That’s the proposition of using a standard format of communication. With not too much of a rewrite you could use either MSSQL or Postgres for example.
Working in a database first company where more than half of our business logic is written in scalar functions and stored procedures, I have to say I understand his sentiment. If there would be an actual programming language that would interact directly with a database (and not just an orm that translates to sql), it would be a very interesting new approach. It would give all the benefits of (modern) programming languages without sacrificing performance and without it becoming impossible to debug/maintain because you can't understand why the orm converts it the wrong way.
PL/SQL?
EdgeDB is basically heading in this direction and gets most of the way there even now!
It doesn't matter what tech stack you're using, there's a guy like this author that is ready to crap on it.
Back in 2005 you also had to pay ISO if you wanted the full ISO/IEC 16262 / ES3 specification and it came in a crappy PDF.
The text aspect is a feature. You write your operation and send it to the db to compile to prepared statements once. You get new features and optimizations without relying on a binary protocol.
Queries then use the prepared statements to communicate with the db in a terse binary format.
If you don’t use prepared statements your integration layer sucks or you should switch databases.
Here are some more alternatives to SQL (as a database language) that I haven't seen here - for the perspective:
Tutorial D - from C.J. Date's database book; it is not an industrial language, but IMO could be made as such (like, Pascal was also a tutorial language at the beginning 😜)
Prolog - that's logical language, but its queries-predicates are "relational"; just need to make it more practical from the database point of view (like, field selection and all such things)
I'm personally OK with SQL, although sometimes it's getting a bit wordy when you need to do some complicated joins - would be great if we could have some expressive/recursive stuff 🙃
While yes, both languages written for the JVM and for LLVM will be able to run on most systems, and both first compile down to an intermediate language, their back ends are very difficult. JVM takes the JVM-byte-code and then interprets it, while LLVM instead takes the LLVM-IR and compiles it down to machine for the system you're compiling to.
Unless you use the Graal tools, because then you can compile to native too.
And so does the CLR, which consumes IL and compiles that into machine code, and which the author totally forgot to mention. Yes, I am talking about DotNet.
But on the other hand, since LLVM is mostly for low level languages, that one should be compared to GCC as well, the most important compiler platform on Linux, but compiles for more platforms as well.
barmaby has all the exp and skills he should just make the future of database aka BARNABYQL
The biggest thing holding back sql is the lack of good tooling for it (I say this as someone trying to learn sql better). We really just need a good sql lsp that communicates with your database to understand the schema
Even a sql lsp can’t guess though what columns you might be typing, since select comes before the from clause. Otherwise, ye you right
@@apoggione8you can though, but you actually need to be connected to the DB.
Most dB client I use (Beekeeper, DBeaver, BigQuery, hell IntelliJ DB Client) has intellisense on table and column name.
Though you're right about needing to go back and forth cursor wise because you need to declare from first before the LSP can suggest columns
No one tries to change SQL because SQL is THE right way of interacting with data. It wasn't improvised by a techbro in an ephemeral startup, it was thoughtfully designed by a mathematician at IBM labs based on a solid relational algebra foundation.
SQL is something like 50 years old, lets guess where the shiny new meme languages are in 50 years.
Postgres's SQL syntax and out of the box set of functions is ergonimically 1 million times better than any ORM or alterate query interface that I've tried.
While I can't say for postgres's SQL specifically, I can easily get behind the rest. When I tried to learn an ORM, and saw how requests were formed, my thought was : "How is it more desirable than writing raw SQL ?"
Modifying raw SQL is just far easier and readable than changing its object mapped counterpart
@@nlight8769 I've reached the point where I will build everything that's a backend project in postgrest in the proof of concept stage of a project.
Skip the middle man.
A full shipping stable, fast and secure backend that deploys anywhere easily and for most things you could use rest for scales to 10K concurrent users. All inside a database where i can either write in SQL or rust (or a bunch of languages i won't use voluntarily)
Most things will have all it's endpoints done when the schema is done and an hour or two of development time has been added.
I can't help but think that if you were to start from scratch creating a language for interfacing with RDBs, you'd end up with another language that looks exactly like SQL.
Nah, you'd probably at least change it to be "FROM Table SELECT Column" instead of "SELECT Column FROM Table"
That alone is the single biggest flaw with SQL
@@TheLamer5000 I think that's just because we're used to nested data with the paradigms that were created out of OOP-> XML/JSON->SOAP->REST. RDBs were designed to use different row/column values to RELATE to different row/column values in other tables. The table isn't really the thing you care about, the row and subset of columns is what you actually care about. It makes sense to me that you'd start out defining the subset of relevant columns before anything else.
@@davidspagnolo4870 It's more that it makes autocomplete a pain, putting the table first lets the autocomplete load the columns by the time you get to the SELECT Column part
I mean there was MDX with cubes, MQuery with PowerBI, DAX, and now GraphQL. You could say many are for reporting but they are essentially query languages meant to query data with joins.
One must imagine Sisyphus indexed
what do you call a guy who digs up cadavers and stitches them together...?
....A monster
I'm a DJ (database jockey). Seriously, ask anyone I work with and they'll tell you my queries remix the data in ways they never imagined possible.
damn
i'm the only one that cackles every time they say "free market" its like hearing a kid talk about santa claus
OP has big "I've been writing software for 6 years and I think I know everything now" energy.
SQL is 2 things packed together:
- A protocol for an app to store and retrieve information on a database
- A high level language to process, analyze and retrieve data for Data Analysts
Because it's such a standard in outside software engineering - where learning new languages every other month is common - SQL will not move.
However we could totally think about a way to optimize the interaction between apps and databases with a fast and type-safe system, for the first use-case. But the system will still need to be SQL compatible :)
If I ever work on a database or an ORM, I am 100% calling it Squeal
Surreptitiously brainstorm an acronym to have in your pocket for that meeting and get a branch or the database or something named PIG (PRIVATE INTERNAL GIT) or SWINE, or something. Once it's established, that's when you bust out the PIGGY squeeeels
I just knew that Prime would talk about the Sisyphus show on Netflix, when he read Sisyphean. And I agree, it was pretty nice!
I think there are two reasons why SQL sticks around. First, the way we use databases hasn't really changed, so SQL is still perfectly adequate for its use case. Second, you usually aren't pumping out hundreds or thousands of lines of SQL every day like you are with other languages. If I'm tasked with fetching some data from a database and presenting it on a web page then the SQL is a tiny fraction of the code I need to write, so it's not really the part of my workflow that I'm most eager to optimize.
Why need diversity when even a Business Analyst, a Sales Manager or even a Marketing Specialist can easily learn and write Squeal to get the information they need? Squeal is not really invented for programmers.
FYI, I'm DBA/Data engineer and I grant read access to those people.
Sql can get very complex though .
@@ci6516 That's when the big bosses spend big money on BI platforms such as PowerBI or Tableau
The minor difference between different version of SQL already causes me enough headaches. I don't need a new version of something that is actively supported and already does what I want it to do. If anything, SQL could be more unified if not for proprietary nonsense.
Someone show this guy the monstrosity of the query language of ElasticSearch and then let's hear him complain about SQL.
I think SQL itself can defo be redone. Why you select the columns before you even get from a table is beyond me. LINQ style is far more friendly for that. I'd love to see something like LLVM, but for databases, i.e. where the query is a compiled piece, and then the language you use compiles to efficient byte code, and then you can have competing query languages and/or compilers for creating a optimal queries
As an ETL dev in a Microsoft shop I love LINQ, but defining "from" first still throws me sometimes, even 8 years into using it. I suppose there really is a bit of Stockholm Syndrome in SQL, as it didn't occur to me until I saw your comment that I just default to writing "select * from", defining the table and any joins, then going back to the select to define the columns. Been writing queries this way in SSMS for so many years now that it's just muscle memory at this point.
SQL is a bad language for thinking about how to construct and operate on datasets, its syntax doesnt reflect the process of thought, you kinda have to invert it. It quickly becomes unreadable on sufficently complex operation. Examples of good aproaches to to this problem are Hadley Wickhams dplyr or sparksql, you chain verbs and get what you want
why is my freemarket not freemarketing like it should ?
I am blessed to have learned dplyr exists and its a shame it's such a small subset of people that even know of its existence
don't get me triggered by even mentioning anything R-related
thanks for covering my article! I think it's about 2 years old so definitely ready for a refresh, great feedback on the content too!
No offense, but I think it needs to be rewritten when you're sober.
Your this years article from April reads far better, though I would argue it doesn't go far enough in better implementation of alternative query data structures.
@@Nors2Ka appreciate the blunt and honest feedback, it's the best kind of feedback! I am definitely going to rewrite this. It was half-assed at best and takes WAY too long to get the the actual point.
Now that I've actually designed and partially built this SQL-less-relational-database product it'll be much clearer in my mind to articulate what I was trying to get across back then.
Thanks again!
@@BarnabyKeene Sounds good.
As it happens I have a "write a database the way I'd like it" on my bucket list as well, so could be interesting to see what you come up with.
@@Nors2Ka for sure! do you have a twitter/github?
With respect: you needed to *start* with substantive, concrete criticisms of SQL the language; that's largely why nobody understood what you meant. Linking to the EdgeDB piece wasn't enough because Primeagen hasn't read it and neither has anyone else who watched. Just witness how many people think SQL is synonymous with the relational algebra itself. People would never make that mistake in any other context; it's like thinking C is synonymous with manual memory management, and that doing it any other way or with a new language is unthinkable.
19:06 I think ORM and query builders are 2 different things. but they can be designed to be plugged together
Saying SQL needs to be diverse is like saying we should have browsers that throw out the back button and the address bar. Or why do we use for loops in all programming languages? Why not invent a new loop type?
Function in a sensible language: def square(n) = n*n
Function in SQL: CREATE FUNCTION square(n double precision) RETURNS double precision STRICT IMMUTABLE PARALLEL SAFE AS $$ SELECT n*n; $$;
And a procedure with multiple statements is much worse.
The more the article goes on the more it sounds like his problem is not the SQL DB's themselves... but learning to integrate different systems. And to this day 'I'm a GO programmer" sounds so strange to me, when we have systems still in production a few decades older than GO :))
There ain't no competition when you got perfection. Sql works, and probably always will, for the vast majority of data use cases.
SQL facilitates backup and redundancy and disaster recovery using its transaction log, we can call it a leaky abstraction. We can criticise SQL as an API to safely manage transactions but referring to it as an SDK is wrong. The article neglects all database operating aspects, database operating is usually the important part when you consider which database you use, the query language is an after-thought and that's how it should remain. You want your DB as strong as a cockroach, not your API.
The other thing I'm not sure this guy understands about SQL (and databases in general) is that it's *imperative* to have longevity.
Records stored in databases may be referred back to decades in the future. If you have a fast-moving tool which increases the amount of migration work you have to perform, the chance of data loss increases too.
Databases are not microservices that can be hot-swapped on a whim. There is little scope for trial and error. If you want to play that game, you need to rethink and break apart the entire database architecture
Cypher, which is used in neo4j, is a pretty interesting query language, since it's a graph db
Yeah, I've been using only neo4j for 5+ years now. I would never chose SQL by choice.
@@pinatacolada7986 what do you use it for out of curiosity?
It just sounds like they want a "good" abstraction from SQL
I don't think that SQL needs a replacement since it is easy to understand and use as long as you understand Set Theory - and SQL itself isn't really comparable to a programming language as it pretty much only describes what the result should look like, not how to get there (HTML/CSS is more similar to SQL in that regard than a "real" programming language)
although to be fair, databases extend SQL in a way to give control over how it is done too (with transaction controls, lock controls, database settings etc.)
In a way, SQL *is* the abstraction, I rather want access to the underlying layer to write a *different* abstraction.
The problem is, that layer is often very tightly coupled to the actual parsing of SQL itself. I almost managed it with Postgres' but writing C makes my small brain hurt :(
SQL is the assembly of databases
Or, now hear me out, they want something theu don't need an abstraction layer on.
How is it nobody sees the m benefit of a usable system without 10 layers of obfuscation?
If you're interacting directly with the database, sure, SQL is fine. But it's horrid API design because it's all text and someone can easily bobby tables your production database.
@@__Brandon__ you could argue that query plans are the assembly of databases, and SQL is the... javascript!? but maybe what I want is a common query plan format that's akin to LLVM IR!
Gf enters the room
(in Primeagen voice) "What makes cockroach nice isn't the squeel... it's the things around the squeel" 👀
No mention of datalog use (in datomic/datascript/datahike/xtdb) in this article seems like a huge oversight.
the time for sql is the time for c. They're around this long because they do that one thing almost infallibly.
So... if Rust is good, C++ bad, specs good, but we don't mention that Rust's spec is literally "whatever the compiler's doing".
Datomic is an alternative to SQL and using it feels like writing pure math, so I think its really hard to write a simple interface
SQL database is a mathematical abstraction of how to store and manipulate data using tables, the SQL is tied closely to it. it not going to change. if you have other ways of abstracting data you are welcome to try but tables are just so easy visualised and used
OP: wahh, ANSI is too complex for beginners to make their own app
Also OP: wahh, ANSI isn’t free for beginners to make their own app
I'm using Active Record to interact with RDBMS.
Of course I do know how to writes tests (using RSpec) to make things reliable and maintainable.
Personally, I don't have much complain, everything works smoothly.
Guys, plumbing hasn't changed for the last 150 years. It's obselete. We need innovation in toilets
Maybe if it was innovated, plumbers would lose their jobs, because a lot of old systems can't handle someone shitting "too much", if you will. They also can't handle grease, or wet wipes, or many other things people flush down the drain, and believe it or not, people will continue flushing these things down the drain no matter what excuse you give.
Why SQL stays around so long is perhaps for the same reason COBOL and FORTRAN are still around....
I would say trying to remove SQL and replace it, would be like trying to replace ASCII. Not in the sense of extending it like with UTF-8, but actually replacing it in a manner which is fundametnally incompatible. For example, one "great idea" would be to put the numbers from 0 to 9, followed directly by capital letters for easy representation of numbers in base 10 or hex or even base 36.
SQL has moved slowly as a feature. It’s a standard implemented (more or less) by a hundred different engines and tools used in production, and this interop is key to its success and one reason why we can rely on it for building long-lived systems.
I do applaud the attempt to improve databases but the comparison to open markets is missing the point: market forces drive innovation when the success of the innovator brings more value to customers at the expense of the existing product vendor. But when your innovation is to replace a standard with a fundamentally incompatible one, it’s not at the expense of the old busted software vendor, it is at the expense of ecosystem interop. It hurts everyone, especially the customers, who get locked into a walled garden of the new paradigm/standard until maybe someday when everyone else migrates too.
SQL works, and for good reason: you can do all of the low level operations you need with the datasets. SQL creates and returns datasets. That is all it is intended to do, and that is all it does. What you do with it is up to you. The obsession with abstraction and layers upon layers of skill removal IS Stockholm Syndrome.
sql was made to make a standart so people could use ibm data bases, oracle or any other with the same query without having to do migration. -so it was made that way baby no whinning up
I think what the article is trying to say is that how data is needed in code is very different from how fundamentally SQL is designed. SQL is designed for humans to query data from a database but not for a machine and so we end up with tons of ORMs that translate your codes data needs to this human oriented query language called SQL.
This translation from a code data requirement to SQL might often lead to the ORM producing subpar queries where as if the database exposed APIs to do the dirty work the entire translation step would be skipped and ORMs might become better and probably the defacto way we talk to a database
I think sqlite's continued popularity and dominance is evidence the relational model and SQL are pretty strong. A circumstance where SQL/relational databases doesn't feel like the default option at all, but still proves itself well.
I don't really understand what the article's point exactly is. Normally, I'd say people who are like "umm SQL database isn't the same thing as Relational DB's, that's just the query language" are pedantic but this is one of those cases where I'm legitimately confused where his issue lies. And the distinction needs to be drawn.
The free market argument is confusing, does this not apply to relational DB's and SQL? If not, how come we seem to keep seeing competitors to relational databases that in the end never seem to do little more than take a chip out for some niche. And if so, wouldn't its persistence be evidence it's quite a strong model
I think the comparison here is more like how all of the browsers use JS. But none the less, I do think it's a pain to have to write all of your database interactions in two languages and be forced to keep them up to date together. The only way around this is to use an ORM, which has a lot of other tradeoffs, and then if you use one like diesel, you still end up writing all of your migrations in raw SQL anyway.
Complaining about relational databases using a textual representation for their query description is not significantly different from complaining about browsers using a textual representation for their document description.
Both are universally used within their domain, provide interoperability through a common language specification, and neither provides static analysis or type safety within their host server language, nor do they “foster an ecosystem of novel approaches to interface design.”
That said, HTML is a *bit* lower level, and is broadly context-free. I could write an object model for an HTML-like language (e.g. a tree where nodes have metadata) without much difficulty, whereas doing so with SQL is a larger - but by no means impossible - undertaking. (Arel in Ruby and Linq in C#/.NET both come to mind.)
The bigger complaints here seems to be “SQL queries are hard to compose” and “I have to issue SQL queries via an abstract API, so my ResultSet comes back untyped” - neither of which is wrong, but both of which are solvable with a little library code (plus an LSP, if you feel like treating yourself).
I had to get data from a PIC database once. It was hellish, for those that do not know, each field on each record can hold one piece of data in every type, so not only do you need to know the table and field (which the query language doesn't seem to like giving you) but you also have to know what datatype the specific data is and hope like hell the interface forced the users to use specific datatypes for the fields (they never do). I wished it had more tools like SQL does.
That being said, when you deal with objects (where the data is always an n-dimensional object which may then relate to other objects of varying dimensional depth) vs 2 dimensional related data a relational database may not be appropriate, for instance velocity db is a NoSQL db that is used in air traffic control due to the speed and reliability features. Each aeroplane has a distinct set of objects associated with it which are never related by themselves. So here is a different method of db interaction than using SQL or a 2d relational model like most SQL dbs are. They generally interact with your development language in it's own native manner (in most cases).
Mongo DB now uses Realm's (NoSQL) paid cloud sync as it's backend instead of the original mongo db, the foundation of Realm is a completely open source project and it uses APIs in languages to access it in an object oriented way, this includes the migration, the schema, and it means if you really want you can change the schema in dynamic ways (personally I would avoid this;). So I'm unsure why he thinks there is no competition, there is and in certain areas it is actually becoming more prevalent. In this manner you can interact with your data in the same way you would any native object you had created rather than using a different language between your code and your data.
When I was testing using benchmarks between postgres, mssql, realm, velocitydb, raven and others for loading and reading 1 million small animal records (40 data points + % accuracy, + history, + the pedigree with all their own records recursively) the slowest were the SQL dbs.
In our testing, loading the animal data into the dbs took SQL hours (MSSQL would crash unless you treated it special, postgres coped ok), on the same server Raven took ~31-40s, Realm took 24-26s, & VelocityDB took 12s. These were all saved then reloaded fresh, and random lookups were then conducted and benchmarked again. SQL would take ~15-40s for a single animal record with 6 gens of pedigree (up to 65 individuals), something that when you need to push 500-1000 animals through the crush can slow things down immensely, just the loading times for the animal data we worked out to around ~7-10 hours, let alone then checking the data, recording ~5-10 trait data points, and then herding them into the correct areas and waiting for the data to be saved before the next animal loaded.
When we tested using the NoSQL db it could pull up all the same info in ~15-25ms (most of this being the I/O time).
So yeah no idea where he gets the idea that there is no competition with SQL. He seems to be conflating SQL with SQL tools for writing queries, the relational db model, and dodgy methods of using SQL inside other languages (using strings for queries is a good way to get hammered by injection attacks, please start setting up and using stored procedures), I still work with SQL on a daily basis and write new SQL queries by hand as I have never found a tool that works really well at making good, optimised queries, it's not hard (heck I found react and angular harder in the day).
Tbh there are two good reasons.
1) We haven't found a way to interface with databases in code that doesn't suck way harder than just using SQL
2) I do a lot of work in an SQL REPL and I'd much prefer not having to write JavaScript to see what's in the table (I'm looking at you, mysqlsh, though I know you can switch to SQL). Trying to use mysqlsh to dump a table from a Non-JS or non-Python language is enough of a pain as it is. Generating Javascript code in bash is not fun...
On the other hand I'd be all for a sequel to SQL. The language is an unstructured nightmare, and parsing it is a massive undertaking.
I think people use transactional databases too much. It's often a needless complexity. But I won't deny that you get a lot with that complexity.
SQL isn't all the same either, there are SQL flavors and variants based on the providers and engine. Postgresql is slightly different from MYSQL and MSSQL
Sounds like the young guy that learned about a "shiny new thing" and thinks that everyone else is wrong for using the 'old thing'.
The guy has absolutely missed PRQL, it's awesome btw
This rant from the article's author is very strange. SQL is a declarative language and as such describe what information and how the user wants the information to be presented (always in grid form). It is implementation independent (for the most part). Make your own. There are other database noSQL paradigm: objects or documents based.
Counterpoint: Cypher for neo4j. It makes a LOT of sense, and the only downside is that all the existing integrations for things assume you're using SQL.
I'm not a software enginer by a long stretch, but I feel like the only reason why you'd want to send bytes instead of text for querying your DB server is for performance. The rest can all be done by changing your library/way you construct those queries.
What I learned from this video is that Go is for the web, and if you don't web, you don't Go, and fuck the web.
what prime is saying is despite every sql are the same. their differences and their underlying function i.e maybe its for analytical, transactional, horizonal reading,real-time, all db are still different even if they use the same familar dialect they have some degree of specialized parts.. its like if else and loops its just there for familiarity.. heck even in plain human languages
Lol basically like saying “All languages use verbs and nouns, where’s the free market place of ideas?”
Waiting for the next article arguing that we should have web browsers that use something other than JavaScript.
The whole "SQL is too hard" crowd need to build something at least as good before they go criticising.
I watched it for 30 minutes, rewinded, jumped around in case I've missed something but still not sure what this guy is really about.
The problem with this article is he never explains why SQL is holding back design, other than some vague sweeping complaints about the spec. My only complaint about SQL is that a KV database is objectively simpiler, faster and easier to use, but you only ever find ACID compliant SQLite, or non-ACID json or ad-hoc configuration files, or some custom serialization format, instead of ACID complaint Redis or lmdb store. lmdb is just as reliable as SQLite, and faster, but no one uses it, everytime I play Terraria or Factorio I just wish it didn't hitch every time it went to save. You can prevent item duplication bugs with transactions and save at 120fps with restore points and all sorts of crazy stuff. SQL is overkill if you just want ACID compliant data storage.
I like EdgeDB for an RDBMS that uses a language that's more programmer friendly than SQL, migrates itself and does it well, and has a better schema definition format.
8:54 there are sooo many improvements that can be made to SQL even without inventing something by totally new. First, put FROM statements first. How can you get code completion in your SELECT clauses without knowing which tables the data will come from? Second, name table relationships. Instead of joining, you use the relationship name. There are so many query patterns that could be abstracted, though I guess that’s what stored procedures are for. The other thing that gets me is that all RDBMs are also inherently object/graph databases. So in theory, they could all have object/qraph QL applied. The other other thing, is that SQL or an improved derivative language could be used by clients instead of GraphQL to query APIs. The whole data persistence part could be abstracted so that you get secure decoupling between the domain data and the persisted data.
Named table relationships is a cool idea.
At 11:45 DJ stands for "Database Joiner" in this case.
The argument against SQL fails for the same reason arguments against JavaScript fail.
Everyone knows JS is bad but who can really kill it at this point? Are we not doomed to live in a world where JS is both the most used language and the most broken at the same time?
The author watched one uncle bob video on how sql is bad and immediately began writing a whole ass article 😂
I let him cook but he made rocks then smoked them. Diversity isn't a linguistic strength that's why there is DB competition but they try to keep the language the same. It's a non-starter to say learn this new thing to do something you can already do and even then this new thing may not even do what want.
The domain that SQL covers is also pretty small, it's focus is tight and so we should expect to see that reflected in the lexicon just like we do. I think if you try to re-invent SQL you'll end up with SQL that uses different key words because there aren't that many ways to say "pull this data from this location matching this criteria".