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

151–160 of 260 posts

Re: A Critique of SQL, 40 Years Later

#151

Post by tremon »

RedShift1 wrote: post #48
jokoon wrote: post #47

I wish there were SQL "primitives" functions instead of the SQL language. For example if I want to pick a single row by id, with SQL I must send a query string, which results in parsing, which means lower latency. If I want to randomly select 100k rows among a database of 1 million entries, I need to build 10k query strings (I think?), which won't be fast to parse. I don't think this happens when using C pointers in…

Isn't that what prepared statements solve? Only parsed on the first execution and after that only the parameters change.

Exactly. Prepared statements or stored procedures avoid the continuous re-parsing of identical queries.

Re: A Critique of SQL, 40 Years Later

#152

Post by tremon »

gibsonf1 wrote: post #59
warrenm wrote: post #30

Earlier quoted context omitted.

I work extensively with Splunk which is dominantly based on noSQL underneath (MongoDB, among other, proprietary technologies) I've also recently been [re]introduced to graph databases (which are highly similar to the pre-relational network database paradigm) You can simulate graph relationships with an RDBMS or noSQL - but you shouldn't You can simulate an RDBMS with a graph db or noSQL - but you shouldn't You can si…

But thats just it, having many silos for connected information is just not the way we humans do it, nor necessary. A single conceptually indexed space/time hypergraph (as we humans do it) for any part of the world is all you need, scalable up to many billions of edges for that one part of the world.

having many silos for connected information is just not the way we humans do it

What do you mean? I can think of many silos containing connected information: municipal residence records, marriage registries, birth records, police reports, tax records, medical records (for each hospital) are all silos connected by a citizen's identity.

Re: A Critique of SQL, 40 Years Later

#153

Post by isitmadeofglass »

toto444 wrote: post #14
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…

Every time SQL is mentioned on HN someone comes to complain about FROM coming after SELECT. I use SQL every day and not a single time have I found reason to complain about it. Can you give a bit more detail about what's wrong with it being like it is ? EDIT : thanks all for your reply. I now understand that it is an IDE related thing not something fundamental to the language.

> thing not something fundamental to the language.

It is fundamental to the language. The evaluation order is from,where,group by, having, select, order by, limit.

Everything in perfect order is, select except.

Re: A Critique of SQL, 40 Years Later

#156

Post by eatonphil »

vendiddy wrote: post #5
dominotw wrote: post #3

SQL is having somewhat of a moment in the bigdata world, thanks in part to 'modern datastack' and new age datawarehouses like snowflake,bigquery. However there are a lot of pushback from 'traditional' dataengineers who were trained on spark/scala. Its bit of hardsell to go from a highly typed language to a free for all text based logic. I think the following is needed for sql to be finally accepted as 'serious' conte…

I think these are great suggestions. It seems like you're suggesting that someone could design a functional-style programming language that compiles to SQL. 2 & 3 are my biggest pain points. I can't just extract functions like I can with a regular programming language. Instead, SQL queries get increasingly complex with no great tools to manage that. For 3, products like https://materialize.com/ look interesting for b…

> It seems like you're suggesting that someone could design a functional-style programming language that compiles to SQL.

Not exactly but sort of this:

http://blog.hydromatic.net/2020/02/25/morel-a-functional-lan...

Re: A Critique of SQL, 40 Years Later

#157

Post by merb »

bearjaws wrote: post #8

The only thing I would really blame solely on SQL is that UPDATE and DELETE statements don't require you to specify a limit. I have seen many times in my career where a rogue delete just truncates a table, a simple statement of intent (e.g. LIMIT 1) would tell the query planner that if it is about update/delete more than 1 row, it should error. In fact MySQL actually returns a warning if you do this. TRUNCATE clearly…

> TRUNCATE clearly states your intention to delete everything, but DELETE by default also deletes everything.

btw. they are completly different.

TRUNCATE basically ignores all transaction semantices for the sake of performance (which can be really really bad) in mysql it can't be rolled back, in postgres it's not mvcc safe. TRUNCATE most often uses either an exclusive lock or some other mechanism.

if you know what you are doing truncate can be helpful, but delete has its benefits as well and truncate should be avoided by beginners.

Re: A Critique of SQL, 40 Years Later

#158

Post by qorrect »

tehlike wrote: post #138
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…

Check this out https://github.com/prql/prql

Love PRQL :D

Re: A Critique of SQL, 40 Years Later

#159

Post by qorrect »

mordechai9000 wrote: post #83
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…

Maybe we should treat SQL like JavaScript, and use it as a compiler target instead of coding in it directly. /s

I know you're being sarcastic, but yes!

Re: A Critique of SQL, 40 Years Later

#160

Post by bot41 »

The_Colonel wrote: post #107
noirscape wrote: post #53

Earlier quoted context omitted.

DESCRIBE TABLE is a command that pretty much does exactly this (explain what a table contains) and it's a part of MySQL. If you use PostgreSQL then you can use \d instead. I'm sure the other RDBMSes have their own equivalent (except for maybe SQLite but if you're using SQLite outside of toy environments or hobby projects, you're doing it wrong).

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

sheesh lets hope there are no vulnerabilities in there
Post reply on HN