We Can Do Better Than SQL • Hacker News Board

Re: We Can Do Better Than SQL

#301

Post by gboss » Tue, Aug 11, 2020, 1:19 PM UTC

goto11 wrote: post #291

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. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

Slightly tangential but I really like Linq syntax. The only problem I have with it is that it is really hard to debug if there is a logic error. I often see developers write linq find out the record set they get back is incorrect and then break up the linq query to a nested if clause to get what they want.

Re: We Can Do Better Than SQL

#302

Post by exabrial » Tue, Aug 11, 2020, 1:20 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…

I had three college classes that really sealed this up for me: linear algebra, a set theory 'light' class, and a class on database mechanics itself. After than I was able to reason about mathematical sets, and scalar functions and what the database engine is doing.

If you "just learn SQL" without understanding the abstraction below it, it'll be difficult to be successful, much the same with anything else.

Re: We Can Do Better Than SQL

#303

Post by peterwwillis » Tue, Aug 11, 2020, 1:20 PM UTC

If you want people to take your replacement language seriously, lead with an RFC that's been reviewed by industry peers. We all know the status quo sucks, but it's the status quo for a reason.

Re: We Can Do Better Than SQL

#304

Post by tsimionescu » Tue, Aug 11, 2020, 1:21 PM UTC

unityByFreedom wrote: post #285

cafard wrote: post #281

Earlier quoted context omitted.

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.

The diff tool is the key here. Without that, there is no meaningful version control.

Re: We Can Do Better Than SQL

#305

Post by jimbokun » Tue, Aug 11, 2020, 1:21 PM UTC

lmm wrote: post #116

bjo590 wrote: post #90

Earlier quoted context omitted.

> 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” The thing about SQL is that it's the fastest way to read&write data in a relational database. Maybe writing the code is faster in js/swift/php, but the code will run faster in SQL. If you need to do something to 100M pieces of data you can do a lot worse than SQL.

That's circular reasoning though. Why do you want your data to be in a relational database? Particularly if you're not actually using its features (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example). A different kind of datastore could offer you better performance and easier querying.

> (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example)

You only ever have one user in your web applications at a time?

> A different kind of datastore could offer you better performance and easier querying.

Citation needed.

The so called "NoSQL" systems manage to scale better because they have very constrained query models. So they are only "easier", perhaps, in the sense of supporting less functionality, but in most cases that leads to a big increase in complexity in the rest of the application code.

Re: We Can Do Better Than SQL

#306

Post by paublyrne » Tue, Aug 11, 2020, 1:24 PM UTC

dahfizz wrote: post #296

g5becks wrote: post #282

Earlier quoted context omitted.

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.

In what language is that used? It reminds me of pipes in bash. I can see it being useful in circumstances where you have lots of function calls and fewer arguments (just like pipes), but I think it would look really ugly and hard to parse with a long arg list.

Elixir for one.

Yes it works best when you have one argument to pass, as the first argument is passed implicitly.

https://hexdocs.pm/elixir/Kernel.html#%7C%3E/2

Re: We Can Do Better Than SQL

#307

Post by jdmichal » Tue, Aug 11, 2020, 1:29 PM UTC

dahfizz wrote: post #296

g5becks wrote: post #282

Earlier quoted context omitted.

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.

In what language is that used? It reminds me of pipes in bash. I can see it being useful in circumstances where you have lots of function calls and fewer arguments (just like pipes), but I think it would look really ugly and hard to parse with a long arg list.

It's a common functional thing. I know F# has both `|>` and `` and `|||>` variants which take two- or three-value tuples and spread them to arguments.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

Re: We Can Do Better Than SQL

#308

Post by oreoftw » Tue, Aug 11, 2020, 1:29 PM UTC

spo81rty wrote: post #300

I love SQL. I HATE using Elasticsearch because it doesn't support SQL. If you ever used Elasticsearch, you know exactly the nightmares I am talking about. Products support SQL because everyone knows it and it works, regardless if it isn't perfect. Trying to create a new version of SQL is ruining your capability to have millions of trained users that already know how to use your product.

Agree. Building elastic query AST is a PITA. Check out https://www.elastic.co/what-is/elasticsearch-sql

Re: We Can Do Better Than SQL

#309

Post by nealabq » Tue, Aug 11, 2020, 1:30 PM UTC

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

It's a mistake if your goal is to have the language implemented and become popular. Otherwise I like the notation.

Computer languages would be different if Ascii had provided code points for ∧ ∨ ∩ ∪ ≡ ↑ etc. It's too bad so much real estate is wasted in the control chars.

Re: We Can Do Better Than SQL

#310

Post by mufufu » Tue, Aug 11, 2020, 1:35 PM UTC

sanderjd wrote: post #289

roenxi wrote: post #181

Earlier quoted context omitted.

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

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

I think the point he is trying to make here is the same as the post was making concerning orthogonality. Having a smaller set of special syntax, and therefore an easier validator to write, means easier queries to write for the user. I don’t think he was implying that everyone who makes use of the language should know how to write a lexer for it.

> The syntax is just not the interesting part. Any syntax that meets those criteria would do.

I have to disagree with this. If this was the case we would still be programming everything in BASIC or C because they’re just another imperative programming language and it gets the job done. Having sugar syntax, a consistent language, etc.. all makes it easier for a programmer (or data analyst) to get the job he needs quicker (and therefore reduces cost), makes a program easier to maintain, and so on.