Against SQL (2021)
scattered-thoughts.net
Against SQL (2021)
1–10 of 81 posts
Re: Against SQL (2021)
#2(2021)
Re: Against SQL (2021)
#3Discussion in 2021 (346 comments): https://news.ycombinator.com/item?id=27791539
Re: Against SQL (2021)
#4TL;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
Re: Against SQL (2021)
#5I'm agnostic between relational/non-relational.
SQL isn't for everything.
Neither is starting with NOSQL thinking it might be better and then proceeding to spend way too many man years making it a relational database, when learning a bit of SQL would have handled it fine.
Re: Against SQL (2021)
#6(2021)
Trying to understand how the year is relevant - still new to folks and still seems relevant.
Re: Against SQL (2021)
#7In 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 always have some proper API abstraction between your components? 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. But the answer can't be have no APIs?
All that said there might be some situations where your goal is to query raw/tabular data from the client. If that's your application then APIs that enable that can make sense. But most applications are not that.
EDIT: FWIW I do think SQL is pretty good at the job it is designed to do. Trying to replace it seems hard and with unclear value.
Re: Against SQL (2021)
#8Question 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.
Re: Against SQL (2021)
#9(2021)
Trying to understand how the year is relevant - still new to folks and still seems relevant.
It's helpful to include the year in the article header because;
Everything may have been true at the time of writing, but details may be obsolete. For example this article refers to Neo4j. Knowing the article is 4 years old helps me understand that comment is not current.
The landscape can change quickly. The older an article the more one takes that into account. Given that this article promotes an alternative technique, Knowing the article is old allows me to wonder if any of the suggestions were gelled, and if so to what success.
In this case, since SQL has been around since the 70s, it's not surprising that the complaints are not novel, and are all likely to be true for years to come. SQL has truly enormous inertia on its side though.
Re: Against SQL (2021)
#10In 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…
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.