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

A Critique of SQL, 40 Years Later

carlineng.com

Post reply on HN
Print view View original

201–210 of 260 posts

Re: A Critique of SQL, 40 Years Later

#201

Post by emmelaich »

ianmcgowan wrote: post #102
crazygringo wrote: post #37

I've written a bajillion queries and have tons of nitpicks, but it's the twin meanings of NULL that really kills me. NULL can be the value of a field in a record, but it is also used to indicate the lack of a record in a JOIN. If I run: SELECT x.a, y.b FROM x LEFT JOIN y on x.a = y.a and I get back [5, NULL] I have no way of knowing if that means there's a record [5, NULL] in table y, or if there's no record in table…

I'd check to see if y.a IS NULL in that situation. I'm sure there are cases where it matters, but most of the time for me the difference between "there's a row in y, but the value is NULL" and "there's no row in y, the value is NULL" is irrelevant. I can't think of a time when that distinction has been important, and I'm working on a project converting thousands of complex SQL queries. The thing that really bugs me a…

'' is NULL in Oracle. People complain about it, and it always seemed a little weird to me.

Re: A Critique of SQL, 40 Years Later

#202

Post by xpe »

gibsonf1 wrote: post #17

I think the issue isn't SQL, but the table paradigm for storing data. Humans do not store data in separate tables that need joining, they store data in a fully connected graph (hyper-graph). Its about relationships and hierarchies - the graph allows incredibly fast hierarchical reasoning, as most things involve hierarchical reasoning. The relational table, and Sql by correlation, are terrible at the human approach to…

"Most things involve hierarchical reasoning" begs the question: what is the universe of processing you assume?

Many would counter by saying basic index lookups comprise a vast majority of DB processing time.

Re: A Critique of SQL, 40 Years Later

#203

Post by xpe »

gfody wrote: post #103
gibsonf1 wrote: post #17

I think the issue isn't SQL, but the table paradigm for storing data. Humans do not store data in separate tables that need joining, they store data in a fully connected graph (hyper-graph). Its about relationships and hierarchies - the graph allows incredibly fast hierarchical reasoning, as most things involve hierarchical reasoning. The relational table, and Sql by correlation, are terrible at the human approach to…

sql doesn't specify how data is stored, it's only a description of the data you want. how your data is connected or not at rest is up to the engine and how you leverage its engine-specific features.

Sort of. "Does not specify" does not mean there is no connection between logical and physical layers. The relational model has strong implications for what a storage engine should do well.

Re: A Critique of SQL, 40 Years Later

#204

Post by 3pm »

SoftTalker wrote: post #188
3pm wrote: post #174

Earlier quoted context omitted.

There is no one-size-fits-all, but most of the time I would be against SP because: 1) SPs usually mix persistence concerns with business logic. Making it harder to understand business intent. I find objects much more expressive than raw data. Sometimes you want to concentrate on the plain logic, without worrying about how something gets saved. Also you will not have to rewrite everything if you ever want to change ho…

In my experience, the application framework changes much more often than the database. PHP, ASP, ASP.NET, Angular, React, Django, whatever. Pick a year, pick a framework. The database stays steady.

I agree. But I found that approaching it _as_if_ database will change makes for a more focused model. Same goes for UI frameworks. Basically thriving toward Hexagonal architecture, without being too dogmatic.

Re: A Critique of SQL, 40 Years Later

#205

Post by goto11 »

BeefWellington wrote: post #114
exabrial wrote: post #10

The only thing that affects my daily life with SQL is that FROM should be before the SELECT keyword. This would _greatly_ improve type-ahead support in SQL IDEs. Nothing is perfect, but that is really the main beef. Another commentor already nailed having a LIMIT WITH ERROR clause to be specified on UPDATE,DELETE statements and explicitly throw an error otherwise. SQL is on of my favorite tools to use and I don't see…

I think this stems from a misunderstanding of the entire point of SQL. It isn't about looking at data in an individual table, it's about retrieving a Result Set for complex queries. All the FROM-first examples I've ever seen are almost universally the simplest query in the world where autocomplete is not a large hurdle anyways because you aren't even bothering with table aliasing. As soon as you do anything even mode…

Joins would presumably still be in the from-clause, so you get:

   FROM a JOIN b JOIN c
   SELECT b._
Here aoutocomplete helps also with the joined tables. Autocomplete would also help in subqueries:

  FROM a JOIN (FROM b WHERE b._

Re: A Critique of SQL, 40 Years Later

#206

Post by gfody »

xpe wrote: post #203
gfody wrote: post #103

Earlier quoted context omitted.

sql doesn't specify how data is stored, it's only a description of the data you want. how your data is connected or not at rest is up to the engine and how you leverage its engine-specific features.

Sort of. "Does not specify" does not mean there is no connection between logical and physical layers. The relational model has strong implications for what a storage engine should do well.

> The relational model has strong implications for what a storage engine should do well.

agreed, the implication is that the engine should do everything well. rdbms is a product of being pulled in every direction, there's generally an index strategy for everything including fully connected hyper graphs, and that's how they ought to be because we can write wildly complex recursive sql queries and the goal is an efficient ideally optimal execution plan

Re: A Critique of SQL, 40 Years Later

#207

Post by randomdata »

mordechai9000 wrote: post #106
ilkhan4 wrote: post #100

Earlier quoted context omitted.

I mean, that's pretty much what ORMs do, right? Hasura et al too.

Yes, this is true. Although my experience with ORMs is that there is always a reason to use some kind of escape hatch to run raw SQL directly.

Most higher level regular programming languages will allow you to escape to C, and C allows you to escape to assembly, so that's not unusual.

In my experience when you need to escape to raw SQL there is still some kind of query builder employed, which too becomes another "compile to SQL" source.

Re: A Critique of SQL, 40 Years Later

#208

Post by aspyct »

exabrial wrote: post #10

The only thing that affects my daily life with SQL is that FROM should be before the SELECT keyword. This would _greatly_ improve type-ahead support in SQL IDEs. Nothing is perfect, but that is really the main beef. Another commentor already nailed having a LIMIT WITH ERROR clause to be specified on UPDATE,DELETE statements and explicitly throw an error otherwise. SQL is on of my favorite tools to use and I don't see…

Agreed.

I would also love to be able to specify the WHERE just after the FROM but before the JOINs. And also after them: - the first one to filter the rows before joining - the second one to filter after joining

Re: A Critique of SQL, 40 Years Later

#209

Post by SPBS »

crazygringo wrote: post #37

I've written a bajillion queries and have tons of nitpicks, but it's the twin meanings of NULL that really kills me. NULL can be the value of a field in a record, but it is also used to indicate the lack of a record in a JOIN. If I run: SELECT x.a, y.b FROM x LEFT JOIN y on x.a = y.a and I get back [5, NULL] I have no way of knowing if that means there's a record [5, NULL] in table y, or if there's no record in table…

Why does it kill you? A NULL in a row is semantically identical to the row never existing in the first place, unless there is some other non-null column (the primary key) that lets you disambiguate between the two cases. It's hardly a problem in practice because all good tables should have primary keys.

Re: A Critique of SQL, 40 Years Later

#210

Post by The_Colonel »

bmacho wrote: post #167
The_Colonel wrote: post #107

Earlier quoted context omitted.

It's kind of funny to see a claim that the most widely deployed database in the world is useful only for toy projects. https://www.sqlite.org/mostdeployed.html

I guess there are more toy projects than serious ones.

Yeah, I mean MacOS, Android, iOS, Chrome, Firefox ... all typical toy projects.
Post reply on HN