There was a bullet in there regarding "poor system cohesion — SQL does not integrate well enough with application languages and protocols." I was curious to hear the authors thoughts on this. I feel ORMs have mostly solved this even while introducing their own set of problems and learning curves. And when you're done fighting your ORM on those bitchy <= 1% queries, well, you just write SQL.
We Can Do Better Than SQL
61–70 of 466 posts
Re: We Can Do Better Than SQL
#62I'm not convinced by a lot of the comments here focusing on SQL as an irreplaceable juggernaut. Currently I think Postgres is just fantastic but recent DBs have shown that even SQL can bleed.
There's some neat stuff here and I hope the project well. I would love to see object/hierarchical result set support grow. SQL ORMs feel so kludgy.
Re: We Can Do Better Than SQL
#63I love critiques of SQL about implementations of NULL. "NULL is so special that it's not equal to anything, not even itself!"
Like, duh. WTF should NULL be equal to?
Anytime I see people making this kind of argument about "doing better than SQL" I can immediately tell they are pretty much fucked in the head.
Good luck, edgedb peeps. You haven't got a clue.
Re: We Can Do Better Than SQL
#64Honestly I think SQL is pretty easy. I love it. I can teach the basics to a new person in minutes. You know what we could do better at? Crappy explains from database engines. Crappy rate limiting capabilities. Poor feedback on keep cache pipelines fed during scans. Poor feedback on column size effects on reading stripes from disk and size alignments between the filesystem and database.
Your brain must work different to mine. SQL is by far the hardest tool I use. I’ve used all the main languages from asm up to js for real work and nothing breaks my brain like SQL.
I use it daily in a business that is heavy on SPs and while I get by and am improving the jump from inner joins and selects to CTEs and the other wizardry is massive.
I want to be better at SQL but so many problems I hit up against and think “well that’s a 2 minute job in js/swift/php”
Re: We Can Do Better Than SQL
#65I love critiques of SQL about implementations of NULL. "NULL is so special that it's not equal to anything, not even itself!" Like, duh. WTF should NULL be equal to? Anytime I see people making this kind of argument about "doing better than SQL" I can immediately tell they are pretty much fucked in the head. Good luck, edgedb peeps. You haven't got a clue.
Maybe if you introduce the concept of a mathematically-principled empty set, you can do away the unprincipled concept of NULL. Empty set equals empty set.
Re: We Can Do Better Than SQL
#66SQL is the COBOL of relational data
Re: We Can Do Better Than SQL
#67Why continue to use the keyword SELECT? It's just annoying.
Re: We Can Do Better Than SQL
#68I'm not impressed for two reasons: 1. Anyone striving to build a better SQL should make a comprehensive list of common (but difficult!) database tasks for OLTP and OLAP workloads. This will expose the weakness of their language. SQL has had 50 years and myriads of improvements to cover all these common cases. This is not a fair fight, so come prepared. 2. It's not enough to be just "better than SQL" to replace it. SQ…
Not disagreeing with your point (if purist language nerds had their way over practicality, we'd all be writing Haskell and Prolog) but most of your nice-to-haves strike me as properties of the database engine, not SQL itself.
Predictable performance - this will always be not only implementation-dependent but data-dependent as well. In order to know whether a join will be efficient or not, you need to know things like relative sizes of the tables, which is not necessarily a language problem. I have worked with SQL implementations that had extensions to let the user annotate joins with relative sizes on each side, but I don't think that's quite what you mean.
Lock ordering - again, good databases should have defined semantics (Postgres, for instance, does take locks in order when using ORDER BY), but I'll grant that this one could be stronger. That said, I think this is pretty niche. How often are you doing large multi-row transactions where lock order is a serious problem? If I have enough volume that deadlock is likely, I probably have enough volume that I want to be breaking up the process into a sharded or two-phase commit anyway.
Ownership relations - I think this is a DDL problem rather than a SQL problem.
Low-level language - I don't think you'll get a portable low-level language here (at least not for any definition of "low level" that's much lower than the SQL AST) because, again, the basics are implementation-dependent. What kind of scan is the base atom of a query? Well, it depends - is your database distributed? sharded? row-store-based? column-store-based? I do wish more open source database drivers would let you play with the AST in memory (Postgres has ways to print it out, but I don't think there's a good API). That would tend to solve the most significant problem raised in the article (composability) - plugging together SQL clauses automatically is hard, but plugging together subtrees can be much easier.
Re: We Can Do Better Than SQL
#69Earlier quoted context omitted.
Ted Codd designed the Relational Calculus as a clean relational-query language. It looks mathematical (scary?) and a little like a set-comprehension. But I think the big mistake is its use of non-ascii chars like ∃ ∈ ∀. Here's an example from http://arwan.lecture.ub.ac.id/files/2013/10/4.-relationalcal... : SQL: SELECT DISTINCT F.Name FROM FACULTY F WHERE NOT EXISTS (SELECT * FROM CLASS C WHERE F.Id=C.InstructorId AN…
I only had a quick look, is it a computer-friendly offshoot of relational algebra[1], the actual mathematical model for relational databases, as an actual query language? [1] https://en.wikipedia.org/wiki/Relational_algebra
Relational calculus is another mathematical model that is dual to relational algebra: if you have one representation you can always get the other. Relational algebra describes a fairly direct set of manipulations of database rows that can be implemented efficiently. Relational calculus operations are more abstract, but have useful identity transformations you can use to optimize query plans.
So, when you ask a database system to perform a query, you ask it in relational algebra terms because they’re easy to understand. It then transforms your query into a relational calculus-like form to shuffle things around, and then back to a different, but equivalent, algebraic form to actually execute.
Re: We Can Do Better Than SQL
#70One word of caution to those trying to improve on SQL - for the many users of SQL, technology is a secondary aspect of their jobs. Hence any replacement runs into the issue that many of its core users do not have the bandwidth to spend significant effort on learning another querying language.
I will cheer everyone who tries to displace SQL, because I do think it needs to be displaced but would also want to caution such people on the magnitude of the task ahead of them.