We Can Do Better Than SQL • Hacker News Board

Re: We Can Do Better Than SQL

#281

Post by cafard » Tue, Aug 11, 2020, 12:26 PM UTC

tsimionescu wrote: post #144

unityByFreedom wrote: post #127

Earlier quoted context omitted.

I completely agree with both the title of this post and your comment. The solution is in diagrammatic "languages"/tools like Airflow, not more query languages. Selecting columns before tables always felt weird to me. Doesn't it make more sense if you had a graphical view this way? (imagine boxes around the below items where you can drag lines to make connections between tables/inputs) USERS --user_id-- [data processi…

Given our source control tools' limitations, I will take a textual format over graphical representation any day. Either way, queries need to be composed at runtime a lot of the time, so for many uses of SQL you can't just have the queries as blobs that you prepare ahead of time in some other tool - they must be objects you can work with programmatically.

Somebody at work just stepped a Microsoft Dynamics "integration". The network admin is trying to recover the integration database from a snapshot. An integration maps data from external files into accounting structures: it uses a GUI, with names that make sense to accountants. And the database that holds it is an Access database with the integration details in a BLOB. I'd pay money for a tool to save these out to a textual representation we could put under source control.

Re: We Can Do Better Than SQL

#282

Post by g5becks » Tue, Aug 11, 2020, 12:29 PM UTC

kd5bjo wrote: post #230

krick wrote: post #222

Earlier quoted context omitted.

> all the syntax decided on before there was a community that really understood what good syntax is Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn…

> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…

Though I program in languages that most follow the obj.method(args) pattern, I really prefer the args |> function |> function pattern and I wish it was the norm in every programming language.

Re: We Can Do Better Than SQL

#283

Post by jacquesm » Tue, Aug 11, 2020, 12:29 PM UTC

grandinj wrote: post #231

jacquesm wrote: post #228

Earlier quoted context omitted.

> SQL was designed by COBOL / NATURAL people and was intended to be used by "normal people". That's not how I remember it. What I recall is that SEQUEL was the result of looking at how databases and set theory could be connected. https://en.wikipedia.org/wiki/Edgar_F._Codd That had nothing whatsoever to do with COBOL or NATURAL.

There is a reason it was originally called (SEQUEL) Structured __English__ Query Language see the original paper at https://web.archive.org/web/20070926212100/http://www.almaden.ibm.com/cs/people/chamberlin/sequel-1974.pdf

I didn't say anything about the name. But you made some pretty strong claims about the provenance of SQL that have - as far as I know it - no bearing on reality. The groups behind NATURAL and COBOL had nothing to do with SQL afaik.

Re: We Can Do Better Than SQL

#284

Post by jtdev » Tue, Aug 11, 2020, 12:31 PM UTC

simonbarker87 wrote: post #64

exabrial wrote: post #36

Honestly 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 thi…

You’re not thinking in sets if you’re constantly inclined to move to js/php/swift. Spend some time trying to break this mental bearier and you’ll find that SQL becomes easier and more sensible.

Re: We Can Do Better Than SQL

#285

Post by unityByFreedom » Tue, Aug 11, 2020, 12:37 PM UTC

cafard wrote: post #281

tsimionescu wrote: post #144

Earlier quoted context omitted.

Given our source control tools' limitations, I will take a textual format over graphical representation any day. Either way, queries need to be composed at runtime a lot of the time, so for many uses of SQL you can't just have the queries as blobs that you prepare ahead of time in some other tool - they must be objects you can work with programmatically.

Somebody at work just stepped a Microsoft Dynamics "integration". The network admin is trying to recover the integration database from a snapshot. An integration maps data from external files into accounting structures: it uses a GUI, with names that make sense to accountants. And the database that holds it is an Access database with the integration details in a BLOB. I'd pay money for a tool to save these out to a t…

There's no reason a diagram can't be in source control. You just need a tool that can convert the diagram to code and the code to a diagram. You probably also want to store the diagram's layout in textual form too so it can be converted back to the original human-created layout.

Then you can use git and optionally build custom tools like a visual diff of diagram v1 vs v2.

Re: We Can Do Better Than SQL

#286

Post by feikname » Tue, Aug 11, 2020, 12:40 PM UTC

kd5bjo wrote: post #230

krick wrote: post #222

Earlier quoted context omitted.

> all the syntax decided on before there was a community that really understood what good syntax is Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn…

> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…

> My pet theory about why the object.method(args) call syntax won is that it really is the most natural to read, as evidenced by the fact that most human languages follow subject-verb-object word order.

Most western languages maybe, but according to wikipedia[1] the most common is actually SOV rather than SVO.

[1] https://en.wikipedia.org/wiki/Word_order#Distribution_of_wor...

Re: We Can Do Better Than SQL

#287

Post by monkeydata » Tue, Aug 11, 2020, 12:45 PM UTC

sql is the language of the gods

Re: We Can Do Better Than SQL

#288

Post by lifthrasiir » Tue, Aug 11, 2020, 12:45 PM UTC

kd5bjo wrote: post #230

krick wrote: post #222

Earlier quoted context omitted.

> all the syntax decided on before there was a community that really understood what good syntax is Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn…

> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…

> [...] as evidenced by the fact that most human languages follow subject-verb-object word order.

Nope. [1]

[1] https://wals.info/chapter/81 (Note that while this is the language count only, the same comment applies to the population using such word order as a native tongue: SOV and SVO are both common.)

Re: We Can Do Better Than SQL

#289

Post by sanderjd » Tue, Aug 11, 2020, 12:54 PM UTC

roenxi wrote: post #181

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…

> SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments…

> It should be possible for an amateur to quickly write an SQL validator as a starting project

...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as a criticism.

SQL hasn't been wildly successful either because of or despite its syntax, it has been wildly successful because organizing data in the relational model and querying it declaratively is extremely powerful. The syntax is just not the interesting part. Any syntax that meets those criteria would do.

Re: We Can Do Better Than SQL

#290

Post by WesleyJohnson » Tue, Aug 11, 2020, 12:58 PM UTC

CodesInChaos wrote: post #272

enjo wrote: post #89

Earlier quoted context omitted.

XKCD’s comic on competing standards feels appropriate here: https://xkcd.com/927/

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.