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

Against SQL (2021)

scattered-thoughts.net

Post reply on HN
Print view View original

41–50 of 81 posts

Re: Against SQL (2021)

#41

Post by gavinray »

YZF wrote: post #7

In my day job the question of SQL and its role keeps coming up. Some people want to propagate SQL all the way to clients like web browsers. Perhaps operating over some virtual/abstract data and not the real physical underlying data (that's a whole other layer of complexity). This seems like a bad idea/API in general. I'm not too familiar with GraphQL but on the surface it seems like another bad idea. Shouldn't you al…

  > My sense for this has been like GraphQL was invented out of the frustration of the frontend team needing to rely on backend teams for adding/changing APIs.
GraphQL was borne out of the frustration of backend teams not DOCUMENTING their API changes.

It's no different ideologically from gRPC, OpenAPI, or OData -- except for the ability to select subsets of fields, which not all of those provide.

Just a type-documented API that the server allows clients to introspect and ask for a listing of operations + schema types.

GQL resolvers are the same code that you'd find behind endpoint handlers for REST "POST /users/1", etc

Re: Against SQL (2021)

#42

Post by throwaway894345 »

pphysch wrote: post #27

I think "SQL" is fine, whatever, I'm used to working with multiple different query and programming languages and dialects. That includes the freedom to define abstractions over SQL that meet my personal needs. Standard SQL is not helpful, though. If that (failed) experiment was ended, database implementations would have even more freedom to explore superior syntax. Prescriptive language standards are a mistake.

I like that SQL is a standard, and it's mostly "fine". Sure, I have to constantly read the man pages because there are half a dozen different ways to do fundamentally similar things, and there are subtle differences between each vendor, and I keep running into silly errors like trailing commas. But it mostly works.

The stuff that is more painful is building any kind of interesting application on top of a database. For example, as far as I know, it's very hard to "type check" a query (to get the "type" returned by a given query). It's also hard to efficiently compose SQL. And as far as I know, there's no standard, bulletproof way to escape SQL ("named parameters" is fine when you need to escape parameters, but most of SQL isn't parameters). There's also no good way to express sum types (a "place" can be a "park" or a "restaurant" or a "library", and each of those have different associated data--I don't need a "has_cycling_trails" boolean column for a restaurant, but I do for a park). There are various workarounds, all deeply unsatisfying.

Re: Against SQL (2021)

#43

Post by 3eb7988a1663 »

procaryote wrote: post #4

TL;DR; * a list of things they don't like in sql * a list of traits they think a replacement should exhibit by negating the first list I was kind of hoping for some example of what this much better language should look like

I like PRQL[0] - fixes stupid warts about SQL.

A few top line items:

  - trailing commas not an error
  - queries can be read/written in linear order, starting with from, and ending on select
  - trivial intermediary keywords (eg you define month_total, and then can re-use month_total in a following calculation, no need to duplicate the calculation logic)
  - no need for a separate `having` keyword when `where` can just be a filter on a group
There is nothing too ground-breaking about it. Just streamlines some logic into a more holistic experience.

[0] https://prql-lang.org/

Re: Against SQL (2021)

#44

Post by gavinray »

GuinansEyebrows wrote: post #8

Question for people who actually write app and SQL code: besides convenience, what is the upside of working with JSON in SQL over having your app construct and parse JSON objects, but storing the data in a database using more primitive types? My relatively inexperienced brain is telling me that it’s probably over complex to store and manipulate JSON objects at the DB level.

  > what is the upside of working with JSON in SQL over having your app construct and parse JSON objects, but storing the data in a database using more primitive types?
You use map-like structures (JSON/HStore, etc) for semi-structured user data that you CAN'T define/know a rigid schema for, ahead-of-time.

Think usescases like: Allowing users to write configuration rules, or lists of custom tag value pairs for (whatever), things of these sorts

Re: Against SQL (2021)

#45

Post by gavinray »

taffer wrote: post #26
GuinansEyebrows wrote: post #8

Question for people who actually write app and SQL code: besides convenience, what is the upside of working with JSON in SQL over having your app construct and parse JSON objects, but storing the data in a database using more primitive types? My relatively inexperienced brain is telling me that it’s probably over complex to store and manipulate JSON objects at the DB level.

I use Postgres JSON functions to return nested results. The database itself contains no JSON; just a well-normalised data model. However, the queries return nested JSON in the format required by the application, e.g. for rendering an HTML template or returning JSON to the client in a single round trip. Check out the old dogs can sort of learn new tricks in this great article: https://www.scattered-thoughts.net/writin…

  > JSON functions to return nested results. The database itself contains no JSON; just a well-normalised data model. However, the queries return nested JSON in the format required by the application
Entirely valid usecase, since the client application is likely going to parse some cartesian product of tabular relationship data into "normalized" JSON array of objects anyways.

Generally, generating the JSON response directly for consumption in the DB is faster.

Re: Against SQL (2021)

#46

Post by thom »

throwaway894345 wrote: post #36
thom wrote: post #21

[flagged]

SQL itself doesn't generate any value, relational databases generate value. SQL is just a frontend for them. Anyway, your snark could be applied to _literally any change_. Are you angry that cars are replacing horses? "Horses generate such incomparable value that there's a steady supply of pro-car posts, like fumes from the vast ocean of their constantly boiling piss". Don't like the cotton gin? "Slave labor generate…

If, after 100 years of cars being available, everybody still rode horses and always got where they're going on time, and car people constantly blogged about it, this would be a great analogy.

Re: Against SQL (2021)

#47

Post by 3eb7988a1663 »

thom wrote: post #46
throwaway894345 wrote: post #36

Earlier quoted context omitted.

SQL itself doesn't generate any value, relational databases generate value. SQL is just a frontend for them. Anyway, your snark could be applied to _literally any change_. Are you angry that cars are replacing horses? "Horses generate such incomparable value that there's a steady supply of pro-car posts, like fumes from the vast ocean of their constantly boiling piss". Don't like the cotton gin? "Slave labor generate…

If, after 100 years of cars being available, everybody still rode horses and always got where they're going on time, and car people constantly blogged about it, this would be a great analogy.

I don't have a choice to use SQL. If I want to speak to a database, there is precisely one language available. Like Javascript on the web for so long.

Re: Against SQL (2021)

#48

Post by tomnipotent »

nevertoolate wrote: post #22
nesarkvechnep wrote: post #10

Earlier quoted context omitted.

I hold a very unpopular opinion of GraphQL. I think it’s a great internal querying API. Every web backend project I’ve worked on tries to implement an API for querying data and it’s usually either fast and inflexible or flexible but slow. GraphQL allows to strike a balance, flexible and reasonably fast, with ways to optimise further.

Question is: do you need that flexibility if you have the backend for frontend? Can you design such a flexible api which makes it possible to iterate faster? If not, you just pay, in the best case, a constant overhead, or worst case, exponential overhead for each request! If you need to spend time optimizing because you have monitoring for slow queries or downtime caused by never terminating queries than most likely…

I always thought it was about developer velocity, in this particular case front-end. With a traditional REST API the front-end team needed to coordinate with the back-end team on specific UX features to determine what needed to be done, which was further exasperated when API's needed to be specialized for iPhone vs. Android vs. Web UI.

GraphQL was supposed to help front-end and back-end meet in the middle by letting front-end write specific queries to satisfy specific UX while back-end could still constrain and optimize performance. Front-end could do their work without having to coordinate with back-end, and back-end could focus on more important things than adding fields to some JSON output.

I think it's important to keep this context in mind to appreciate what problem GraphQL is solving.

Re: Against SQL (2021)

#49

Post by dang »

mitchbob wrote: post #3

Discussion in 2021 (346 comments): https://news.ycombinator.com/item?id=27791539

Thanks! Macroexpanded:

Against SQL (2021) - https://news.ycombinator.com/item?id=43777515 - April 2025 (1 comment)

Against SQL - https://news.ycombinator.com/item?id=40454627 - May 2024 (1 comment)

Against SQL (2021) - https://news.ycombinator.com/item?id=39777515 - March 2024 (1 comment)

Against SQL - https://news.ycombinator.com/item?id=27791539 - July 2021 (339 comments)

Re: Against SQL (2021)

#50

Post by chao- »

tomnipotent wrote: post #48
nevertoolate wrote: post #22

Earlier quoted context omitted.

Question is: do you need that flexibility if you have the backend for frontend? Can you design such a flexible api which makes it possible to iterate faster? If not, you just pay, in the best case, a constant overhead, or worst case, exponential overhead for each request! If you need to spend time optimizing because you have monitoring for slow queries or downtime caused by never terminating queries than most likely…

I always thought it was about developer velocity, in this particular case front-end. With a traditional REST API the front-end team needed to coordinate with the back-end team on specific UX features to determine what needed to be done, which was further exasperated when API's needed to be specialized for iPhone vs. Android vs. Web UI. GraphQL was supposed to help front-end and back-end meet in the middle by letting…

This is my read of the history as well.

This is also the motivation that would lead me to advocate for adopting GraphQL for a product. Moreso than a technical decision, it is an organizational decision regarding resource trade-offs, and where the highest iteration or code churn is expected to be located.

Post reply on HN