We Can Do Better Than SQL • Hacker News Board

Re: We Can Do Better Than SQL

#231

Post by grandinj » Tue, Aug 11, 2020, 10:44 AM UTC

jacquesm wrote: post #228

grandinj wrote: post #191

SQL was designed by COBOL / NATURAL people and was intended to be used by "normal people". That was part of a larger movement at the time to make programming more accessible. Unfortunately (a) that experiment mostly failed (b) the resulting syntax does not compose well at all (c) the syntax does not represent the underlying semantics and mathematical operations well at all. The combined effect is a rather tortured la…

> 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

Re: We Can Do Better Than SQL

#232

Post by mattmanser » Tue, Aug 11, 2020, 10:45 AM UTC

quickthrower2 wrote: post #168

tsimionescu wrote: post #147

Earlier quoted context omitted.

We have ORMs because our programming languages object models are not relational, they are hierarchical - from C to Haskell, everyone goes for highly non-relational data representations. So, when we interact with a relational DB we need some kind of layer to map between the world of relations in the DB and the world of objects in our program.

Correct but I didn’t explain well. I mean the SQL generation is left to the ORM and I think that’s no accident.

Not for the reason you're implying, actually for the opposite reason. I'm from the days of yore, just before ORMs became popular and it basically replaced a lot of boilerplate code, but it wasn't the SQL that was the bulk of it.

It was mainly to save time in writing code to map columns to object properties really, the sql statements themselves were trivial even if you weren't lazy and just used select *.

Also, here's a now mainly historical pain most devs never encounter any more: Before ORMs and the various migrators, your object properties might not have the same name as your SQL columns. Yes, it was dumb when you did it, yes, it caused loads of bugs, yes, it actually happened quite a lot.

Re: We Can Do Better Than SQL

#233

Post by dsego » Tue, Aug 11, 2020, 10:45 AM UTC

reportgunner wrote: post #212

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…

Sorry, but what is hard to understand about SELECT FROM WHERE =

Since it's so easy, I think you won't have a problem with any of the questions on this page: https://www.toptal.com/sql/interview-questions

Re: We Can Do Better Than SQL

#234

Post by lmm » Tue, Aug 11, 2020, 10:47 AM UTC

Akronymus wrote: post #171

lmm wrote: post #158

Earlier quoted context omitted.

I struggle to understand this viewpoint. In my experience business rules are harder to express in SQL than in practically any first-class programming language. "Is this value one of this list of values" - whether that list is hardcoded or dynamically obtained - is completely trivial. (Of course if you apply some double standard where editing your "source code" requires multiple approvals whereas changing your "databa…

With SQL you can enforce it within the datastore. And if some requirement changes, you can instantly enforce it. Eg.: A new foreign key constraint. Also: It is centrally managed, so you don't need to look all over the source code to find the constraints and don't need duplicates either, if you can, for example,change the data at multiple points.

> With SQL you can enforce it within the datastore. And if some requirement changes, you can instantly enforce it. Eg.: A new foreign key constraint.

Which is to say that you have little control over deployment. Adding a new foreign key constraint might block queries for an indeterminate amount of time while a new index is built, but you have no way to introspect or predict that at the SQL level (if you're lucky there might be a specific way to find out via the internals of your particular datastore implementation). PHP fans used to tout being able to just edit the code on the production server as an advantage, but most of us recognise it as the opposite.

> Also: It is centrally managed, so you don't need to look all over the source code to find the constraints and don't need duplicates either, if you can, for example,change the data at multiple points.

If your data is well architected so that you only have a single representation of each piece of data, sure. Equally if your application is well architected you can have a single API where any given thing happens.

Re: We Can Do Better Than SQL

#235

Post by apta » Tue, Aug 11, 2020, 10:48 AM UTC

seer wrote: post #129

I for one would welcome a new alternative to sql. It might not be _this_ alternative, but why not try. SQL is very hard to learn properly, with all of its gotchas and inconsistencies. There are running jokes for noobs truncating their tables due to forgetting a where clause. I’ve seen junior devs crying in tears and throwing their mice just because they needed to debug / optimise a complex query. The mare existence o…

> If we settled for good enough in all cases we wouldn’t have Go or Rust

funnily enough, golang is a regression in practically every front compared to established ecosystems like Java and C#.

Re: We Can Do Better Than SQL

#236

Post by lmm » Tue, Aug 11, 2020, 10:51 AM UTC

PeterisP wrote: post #211

lmm wrote: post #158

Earlier quoted context omitted.

I struggle to understand this viewpoint. In my experience business rules are harder to express in SQL than in practically any first-class programming language. "Is this value one of this list of values" - whether that list is hardcoded or dynamically obtained - is completely trivial. (Of course if you apply some double standard where editing your "source code" requires multiple approvals whereas changing your "databa…

You're arguing that business rules are easier to express in other programming language, but the point of the parent post (and SQL) is that business rules are easier to enforce in SQL. It's trivial to write some code verifying "Is this value one of this list of values", but writing such code not ensure that this constraint will actually be met in 100% of your past and future data. It's very difficult to guarantee that…

> It's very difficult to guarantee that a business constraint expressed in your client app is actually enforced - there can be different versions of your app applying the constraint differently, there can be multiple apps accessing the datastore, there could be manual interventions in various ways to the datastore, the app could have code paths that may cause data insertion or alterations without running that verification in certain conditions, etc; so for all intents and purposes you can't really rely on that constraint.

If you have business logic in your datastore then that puts you in much the same position though. If you have a trigger you might have data written before it was introduced, or queries that ran with it disabled. If you're gradually rolling out a new version then you might have some data that follows a constraint and some that doesn't. And so on.

Re: We Can Do Better Than SQL

#237

Post by quickthrower2 » Tue, Aug 11, 2020, 10:51 AM UTC

nicoburns wrote: post #218

quickthrower2 wrote: post #122

Earlier quoted context omitted.

I love SQL. I'd love someone to make it better for complex queries. Have you seen the enterprise SQL monstrosities. Why do we have ORMs if SQL is perfect?

Completely agree. For example, why isn't there functionality to define aliases for complex expressions and then reuse those through a query. Simple query-local SQL functions would be nice too. I'd love to see a "SQL-like" language that compiles down to SQL itself, much like Babel or TypeScript in the JavaScript world. I think the tricky thing is that there is no single SQL target.

Multi sql targets means it’s even more of an advantage to compile

Re: We Can Do Better Than SQL

#238

Post by Akronymus » Tue, Aug 11, 2020, 10:54 AM UTC

lmm wrote: post #236

PeterisP wrote: post #211

Earlier quoted context omitted.

You're arguing that business rules are easier to express in other programming language, but the point of the parent post (and SQL) is that business rules are easier to enforce in SQL. It's trivial to write some code verifying "Is this value one of this list of values", but writing such code not ensure that this constraint will actually be met in 100% of your past and future data. It's very difficult to guarantee that…

> It's very difficult to guarantee that a business constraint expressed in your client app is actually enforced - there can be different versions of your app applying the constraint differently, there can be multiple apps accessing the datastore, there could be manual interventions in various ways to the datastore, the app could have code paths that may cause data insertion or alterations without running that verific…

For triggers, you can run a procedure that executes it for all past data. Or write a procedure that updates the data to a valid state.

When gradually rolling out, you can have adjusted stored procedures that deal with the different versions, and turn off the old one when it is no longer in use.

So, I fail to see the problems you mentioned.

Re: We Can Do Better Than SQL

#239

Post by lmm » Tue, Aug 11, 2020, 10:57 AM UTC

Akronymus wrote: post #238

lmm wrote: post #236

Earlier quoted context omitted.

> It's very difficult to guarantee that a business constraint expressed in your client app is actually enforced - there can be different versions of your app applying the constraint differently, there can be multiple apps accessing the datastore, there could be manual interventions in various ways to the datastore, the app could have code paths that may cause data insertion or alterations without running that verific…

For triggers, you can run a procedure that executes it for all past data. Or write a procedure that updates the data to a valid state. When gradually rolling out, you can have adjusted stored procedures that deal with the different versions, and turn off the old one when it is no longer in use. So, I fail to see the problems you mentioned.

And with good practices (mainly a decent type system that lets you distinguish between checked and unchecked values) you'll have no problems with constraints in the application layer either.

Re: We Can Do Better Than SQL

#240

Post by dsego » Tue, Aug 11, 2020, 10:58 AM UTC

Wandfarbe wrote: post #161

I'm not doing SQL every day but i have rarely any issues with it. Do we really need to do better than SQL? I don't think so and i also don't think that the chosen new syntax is better. At the end of the day, most critical is not the language but understanding how it works to optimize indezes etc. If you are only able to write simple SQL because you are not good in SQL/Databases, you will not optimize your Database in…

I'm not doing C every day but i have rarely any issues with it.

Do we really need to do better than C? I don't think so and i also don't think that the chosen new syntax is better.

At the end of the day, most critical is not the language but understanding how it works to optimize assembly etc. If you are only able to write simple C because you are not good in C/algorithms, you will not optimize your algorithms independently from the language.

If you are good in C/algorithms, you (or at least i) do not care about syntax details; You just look it up, and get acquainted to your specific underlying microarchitecture.