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

71–80 of 81 posts

Re: Against SQL (2021)

#71

Post by Izkata »

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.

We use json columns to store raw data that comes from API responses or structured files. Anything from there we actually use gets copied out into its own strongly-typed column, but the json column remains as a type of logging/tracking as well as the original source of truth for database migrations if we need to pull a new column out, or track down some odd bug.

Re: Against SQL (2021)

#72

Post by nevertoolate »

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…

I think I understand this, possibly nice for huge client x feature matrix. I don’t have XP in the setup where there is a big separate backend team. In my head there is an alternative implementation: have a separate routing layer (coauthored by backend and frontend). Backend responsibility ends with the service layer. There has to be some domain contract implemented somewhere, question is it is simpler to cut down from a tree or build something on top of components.

Re: Against SQL (2021)

#73

Post by nevertoolate »

gavinray wrote: post #34

I work at (what was previously known as) Hasura. Specifically: the connector bits that deal w/ translating Relational Algebra IR expressed as GraphQL nodes -> SQL engine-specific code. The author's comments about lack of standardization and portability might not get across just how nightmarishly different SQL dialects are. I might put together a list of some of the batshit-insane bugs we've run into, even between ver…

What is the approach? Do you target a subset of sql which you compile onto or you have some runtime dynamic dispatch thing and fight for code reuse with the magic haskell tools?

Re: Against SQL (2021)

#74

Post by grebc »

throwaway894345 wrote: post #65
grebc wrote: post #63

Earlier quoted context omitted.

In MSSQL you can select top 0 * into a temp table and retrieve all the usual column meta data. I’ve written basic custom report writer functionality using this technique that lets users(usually me the developer or a super user) do custom sanitised SQL selects. I assume similar functionality exists in all the different vendors databases.

Yes, you can obviously run queries to get that information, but you can’t do it statically very easily. > I’ve written basic custom report writer functionality using this technique that lets users(usually me the developer or a super user) do custom sanitised SQL selects. I’m not sure how having the column metadata helps you sanitize SQL.

Not sure what you mean by done statically in the context of a report writer?

Columns are added, removed, pivoted, summed etc by the user running the report. This can’t be static but the OP was mentioning how you can’t get column meta data easily.

By sanitised SQL I mean the query is fed to the MSSQL parser and only select & union all is allowed as far queries go(eg. no delete, drops, updates etc).

Re: Against SQL (2021)

#75

Post by nawgz »

YZF wrote: post #53
nawgz wrote: post #20

Earlier quoted context omitted.

Re: GQL - Explain to me what abstraction layer should exist between the data model and what data is loaded into the client? I’ve never understood why injecting arbitrary complexity on top of the data model is wise. Perhaps unfettered write access has its problems, and GQL has permissions that handle this issue plenty gracefully, but I don’t see why your data model should be obfuscated from your clients which rely on…

In my view the abstraction layer should be in the domain of the application. Let's say your software is HR software and you can add and remove employees. The abstraction is "Add an employee with these details". The data model should be completely independent of the abstraction. I.e. nobody should care how the model is implemented (even if in practice it's maybe some relational model that's more or less standard). Sim…

For instance, while I work in small teams, I’ve relied on Hasura GraphQL-Engine a lot for my api. This is a full GQL API automatically generated from your SQL schema, Postgres being the best supported DB. GQL relations are available across foreign keys (or manual joins which I never use), so a well defined normalized schema can have deeply nested queries executed easily with full type safety for the consumer.

Taking an HR example, you could query for an employee, their PTO status and accrual history, their manager, and their reports all in one nice easy query that no one has to write any business logic for, just a schema set up with employees, manager, reports, and PTO tables joined on ID keys.

And in such a case, what abstraction does the backend team need to put in front of the schema? I can’t motivate what this means myself. A well designed DB schema is truly a beautiful contract, and with table and column comments you can even get intellisense docs in the IDE for the front end team building the client.

On the flip side, I agree the write operation should be done thru an API when there is complexity and requirements beyond just writing one row to one table, but read operations are much more graceful and speedier to define in GQL than REST.

Re: Against SQL (2021)

#76

Post by HackerThemAll »

layer8 wrote: post #23

This is mostly all true, but there is little incentive for RDBMS vendors to implement and maintain a second query language, in particular a shared cross-vendor one. Databases are the most long-lived and costly-to-migrate dependencies in IT systems, so keeping the SQL-based interface in parallel for a long time would be mandatory. This is compounded by the standardized SQL-centric database driver APIs like ODBC and JD…

This is mostly all b.s.

Re: Against SQL (2021)

#77

Post by xigoi »

jaredklewis wrote: post #68
jampekka wrote: post #64

Earlier quoted context omitted.

The point is that with a more expressive language new features could be added as libraries instead of changing the language itself. This is right before the paragraph I quoted: "In modern programming languages, the language itself consists of a small number of carefully chosen primitives. Programmers combine these to build up the rest of the functionality, which can be shared in the form of libraries. This lowers the…

Yea I know, I was addressing that in my comment? You have languages like JavaScript which are very “expressive” in that it comes with very little functionality but there are a wealth of libraries you can use to augment this. And this tradeoff is often lamented on HN since it’s never enough to just know JS; you have to know the particular libraries being used by the project. Contrast that with batteries included langu…

Expressiveness and standard library size are unrelated. Python is just as expressive as JavaScript.

Re: Against SQL (2021)

#78

Post by procaryote »

Spivak wrote: post #33
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 think the much better language would be the "no language" database. Throw portability to the wind and just have the client ship the query plan directly. The frontend to the database is howerver you want to expose it in your language of choice. I don't think there's any hope of getting disparate db vendors to agree on a compatible frontend language. It seems easier to externalize it. The closest existing database to…

There are some databases you need to write code to interface with. Somehow, one of the first things people need to add to them is a query language which is either SQL or something worse

I don't love SQL, but somehow the alternatives haven't beaten it yet

Re: Against SQL (2021)

#79

Post by procaryote »

cess11 wrote: post #16
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

Maybe I'm holding TFA wrong but to me it seems like they're hinting at wanting a Prolog-as-database that could also become widely used, unlike actual Prolog. It's not hyper-performant and mega web scale but the object database and Prolog like query language that comes with Picolisp is quite fun and sometimes rather useful, and has helped me think differently about how to model things in the default SQL database engin…

It sounds interesting, although I have learnt both SQL and prolog and one was a lot easier

Re: Against SQL (2021)

#80

Post by cess11 »

procaryote wrote: post #79
cess11 wrote: post #16

Earlier quoted context omitted.

Maybe I'm holding TFA wrong but to me it seems like they're hinting at wanting a Prolog-as-database that could also become widely used, unlike actual Prolog. It's not hyper-performant and mega web scale but the object database and Prolog like query language that comes with Picolisp is quite fun and sometimes rather useful, and has helped me think differently about how to model things in the default SQL database engin…

It sounds interesting, although I have learnt both SQL and prolog and one was a lot easier

I'm actually uncertain whether you likely consider SQL or Prolog easier. To me both of them have a kind of late seventies feel that is kind of foreign compared to a lot of software stuff from the last quarter of a century.

Pilog is similar to both, the basics are kind of easy to learn, it's basically a bit of Lisp:ish syntax and keywords for 'give me a subset from these sets'. But it's a graph of objects instead of tables or atoms.

Post reply on HN