Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

Post reply on HN
Print view View original

361–370 of 466 posts

Re: We Can Do Better Than SQL

#361

Post by lurker458 »

dsego wrote: post #210
marmada wrote: post #203

I see a lot of Stockholm syndrome in this thread / maybe low expectations. Many people are saying SQL isn't that hard to learn but as someone who is new to SQL, I disagree. It takes a max of 15 minutes to understand basic JavaScript/Go/Python primitives and write a program. SQL on the other hand seems much more complex. I might as well be reading Haskell or Lisp. At least those languages are consistent. SQL does not…

People who learn the nitty-gritty details and all the gotchas and tricks in the book, appear to be experts and their job positions depend on it. It's all a bit "ludditic", people confuse this familiarity with arcane commands and proficiency with real expertise and deep knowledge. When you challenge that, you challenge their existence. Knowing how null behaves (Null = null vs null is null) is one of those shibboleths…

At the other side of the fence we have JS/TS experts writing inscrutable one-liners by chaining 15 lodash commands.

Having tried both SQL and the approach of using a programming language + framework of the day, I prefer SQL for data manipulation. It's far easier to troubleshoot, scale, hand-over or maintain in the long run.

Re: We Can Do Better Than SQL

#362

Post by bmh100 »

m000 wrote: post #221
Areading314 wrote: post #141

Earlier quoted context omitted.

Right, it's like criticizing python, or English, for being inconsistent, or "large". Turns out that doesn't matter -- what matters is that the language is useful because it has a wide base of users and libraries, just like SQL does.

Python and English are meant to be general purpose languages, so they are kind of expected to be large and occasionally inconsistent. SQL is (by definition) a domain-specific language which has grown out of proportions. Are there really any SQL libraries in the traditional sense (i.e. reusable/composable SQL code with a well specified API)? SQL "libraries" typically focus on hiding the inconsistencies and the abhorre…

SQL is designed around databases. Python is designed around objects. Clojure is designed around expressions. A table is analogous to a list of objects. None of these languages is more domain-specific than any other.

Re: We Can Do Better Than SQL

#363

Post by mannykannot »

sanderjd wrote: post #350
mannykannot wrote: post #341

Earlier quoted context omitted.

>> It should be possible for an amateur to quickly write an SQL validator as a starting project > ...why? I don't know about amateurs, but if the typical intended user of the language does not have a good grasp of what is and is not valid, they will often be reduced to trying one thing after another until they hit upon something that seems to work, with no real understanding of what it does. This is not how robust, c…

That seems like a completely different point. (Unless I misunderstand what a "SQL validator" is, which is definitely possible.) I do think this way of utilizing SQL is a problem, but I would lay the blame for it at the feet of a lamentably widespread anti-intellectualism in the field. It is true that the relational model is not trivial and must be learned before SQL makes much sense. But it is not too much to expect…

I agree that someone who wants to be a practitioner in this field should understand the relational model, but the issue here is that SQL introduces inconsistencies and complications that are not inherent in the relational model, and, to some extent are avoidable. A justifiable emphasis on professionalism does not absolve SQL of these faults and does not render irrelevant attempts to find better language choices.

Re: We Can Do Better Than SQL

#364

Post by cmrdporcupine »

quickthrower2 wrote: post #120
tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.

I think you might be misunderstanding what a relation is in the relational algebra or relational db. It's not a relationship. A relation is nothing more than a set of sets. Tables are relations, and views are relations. The results of queries are also relations.

This is a common misunderstanding of what the relational in "relational database" means. It's not (primarily) about relationships, except insofar that relationships can be described using relations and queried using relational algebra. But the key concept is that of the mathematical relation, as per Wikipedia:

"In mathematics, an n-ary relation on n sets, is any subset of Cartesian product of the n sets (i.e., a collection of n-tuples)"

So the goal of relational db languages is to provide tools for querying these sets of sets. Joins, Unions, Selections (Restrictions), and Projections are some of the tools that are provided. SQL provides some of these, though often calls them confusing names.

For example, in SQL the "select" keyword begins the query statement, but selection proper (as per relational algebra, also called restriction) is actually what is expressed in the "where" clause. What comes after "select" in your query is technically "projection" (choosing which tuples/columns exist in the output). Many ORMs and similar tools get this messed up, because the authors of them know SQL, but not the relational algebra on which it is nominally based.

Re: We Can Do Better Than SQL

#365

Post by fortran77 »

lostjohnny wrote: post #353
013a wrote: post #336

Earlier quoted context omitted.

A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…

> I would point to MongoDB's query language seriuosly? db.orders.aggregate([ { $lookup: { from: "warehouses", let: { order_item: "$item", order_qty: "$ordered" }, pipeline: [ { $match: { $expr: { $and: [ { $eq: [ "$stock_item", "$$order_item" ] }, { $gte: [ "$instock", "$$order_qty" ] } ] } } }, { $project: { stock_item: 0, _id: 0 } } ], as: "stockdata" } } ]) VS SELECT *, stockdata FROM orders WHERE stockdata IN (SE…

MongoDB is better because it's Web Scale!

http://www.mongodb-is-web-scale.com/

Re: We Can Do Better Than SQL

#366

Post by meritt »

jimsparkman wrote: post #315
marcinzm wrote: post #311

Earlier quoted context omitted.

>For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax. WITH statements alleviate some of this issue by allowing you to write subqueries in any order.

WITH (CTEs) make queries so much more readable and digestible. As a programmer who now does data and SQL, I latched on to these as soon as I found I could reduce repetition in a query with them.

Make sure you understand what optimization fences are and how they affect your performance. CTEs are nice to read but routinely destroy the performance.

[1] https://thoughtbot.com/blog/advanced-postgres-performance-ti...

Re: We Can Do Better Than SQL

#367

Post by bmh100 »

CaptainZapp wrote: post #94
AmericanChopper wrote: post #75

Earlier quoted context omitted.

> Predictable performance - this will always be not only implementation-dependent but data-dependent as well This immediately jumped out at me from the parent comment. It would be entirely possible to implement a query language where you specify a plan for your query. But then you’d immediately lose the “better than SQL” competition, because your complexity and maintainability problems would skyrocket. I’ve had to de…

I wish that I could upvote your comment more than once, because this rings so true. There certainly are (rare) situations, where you need to provide hints in one form or another, but it's really a bloody nightmare to maintain and may completely bork, when you - say - upgrade to a new version of the database engine. I work with relational databases since the early 90s and can give you a no-bullshit money back guarante…

I've found with distributed postgreSQL databases that the optimizer needs more help than you might initially expect. After looking at how the optimizer inefficiently implemented a query, I found a different, but equivalent, way to rewrite the query that could then be efficiently optimized. It's more complicated in the distributed case, because the shard distribution rules have a strong impact on performance. The time needed to re-balance data across shards for a query can be significant.

Re: We Can Do Better Than SQL

#368

Post by CodesInChaos »

WesleyJohnson wrote: post #290
CodesInChaos wrote: post #272

Earlier quoted context omitted.

I don't think treating query languages as a standard is the right comparison here. I think it's great that programming languages have evolved from C or PHP quality languages. I view SQL like PHP, I can write it if I have to, but it's certainly not a language I enjoy working with. EdgeQL has its flaws, but it still looks like a big improvement over SQL to me.

I must be in the minority. I enjoy writing SQL and figuring out clever ways to construct queries to get what I need out of the data. Conversely, I am not a fan of PHP at all, but as you said, will write it if I have to. EdgeQL looks... interesting, but I need to see more to decide for sure. Would be cool if they built out a translator, so you could pass in SQL and get back EdgeQL.

It's a translator, but in the opposite direction. EdgeDB is a postgres frontend that translates EdgeQL and its schema definition language to SQL which it then sends to postgres. (It can also translate GraphQL to EdgeQL to SQL)

I don't think translating from SQL to take a look at the EdgeQL it produces makes much sense, since it'd result in very unidiomatic queries. SQL prefers joins and flat rows, while EdgeQL is based on following links and has great support for nested data output.

Re: We Can Do Better Than SQL

#369

Post by bmh100 »

Flimm wrote: post #194

Yes, SQL has flaws, and the article forgot to mention one of them: you need to build a string to build an SQL query, rather than a more structured object, leading to flaws like SQL injection vulnerabilities, and difficulties adjusting the query. Let's say you're building a CRUD app with search and filtering capabilities. Unless you are using an ORM (which has problems of its own), you might be tempted to build the SQ…

I think this is an unfair comparison. Constructing SQL query strings is risky, because it is essentially dynamically constructing and evaluating code from user input. However, there is no reason why one can't use parameters (like you mention) or even call stored procedures.

Re: We Can Do Better Than SQL

#370

Post by krick »

xiaodai wrote: post #88
nealabq wrote: post #47

Earlier 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…

∃ ∈ ∀. quite natural to me as a pure math grad there exists, in, for all

You don't even need to be a math grad for it to be natural. It's just a natural way to perform set operations, pretty much everybody who knows a little bit of math is familiar with it. End even if you are not, you need like 5-10 minutes to learn it, and then maybe a couple of weeks of using it to become really fluent.

And I feel like "is not ASCII" is pretty silly complaint in 2020 anyways. First of, if these characters would be widely used in 1980, they would be on every keyboard today, same as it was on keyboards for APL. Second, you don't really have them to be literally ∀ and ∃, it could have been &A and &E for example, and then every other IDE, including some fancy product of JetBrains, vim & emacs and most likely even your mysql-cli (at least some wrapper around it written in Python) would turn them into pretty ∀ and ∃ on your screen, same as some editors do for λ.

And third, which is a personal pet peeve of mine (so I probably should keep my mouth shut about that, but I cannot): I really, really wish we'd stop with all this ASCII bullshit already. There's nothing special about ASCII except it's 7-bit. And that's outdated.

It may come as a shock to your average American, but most of the texts in the world are not ASCII, just deal with it. If your product doesn't support that, it probably means it's broken, outdated and will eventually lose to a competition, so you don't do yourself a favour forgetting about that.

And with regards to input, there's nothing complicated about typing ∀ (or anything else like that) on an ordinary US-layout keyboard. For me ∀ is 3 very fluent keystrokes. I use XCompose, which is a blessing, but other operating systems have similar software with similar capabilities as well. I understand that this is not something most people are familiar with, but that's just bad and shouldn't be respected: using a mouse also wasn't familiar to every single PC-user out there. With demand comes the supply.

So I really dream about the day when typing nice, clear syntax like ∀ instead of awkward Perl-like character sequences (to read which you need mentally traumatizing professional deformation and/or an IDE post-processor) becomes the norm of programming.

Post reply on HN