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

Beyond SQL: A relational database for modern applications

fauna.com

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Beyond SQL: A relational database for modern applications

#21

Post by pphysch »

This sales pitch sounds like they really just want to build a better ORM, but doesn't want to admit it, so they embark on the foolish task of reinventing SQL.

> ORMs solve this partially at best at the cost of hiding the capabilities of the underlying database.

This is because all the popular ORMs target SQL instead of a specific RDBMS technology, like Postgres or SQLite. That doesn't have to be the case.

> They also obscure the structure of generated queries, making it difficult to understand the resulting performance implications.

Not quite true, Django for example makes it easy to do raw queries, and every generated query has .query() and .explain() methods to analyze the resulting SQL. This has always been a lame excuse to dismiss ORMs.

Re: Beyond SQL: A relational database for modern applications

#22

Post by briandilley »

I have yet to come across a replacement for SQL that makes it easier, or more concise, while also remaining feature rich. Not knocking this, but SQL is a pretty solid and time-tested technology for querying structured data. Alas, if we don't experiment then I guess we wont get better.

Re: Beyond SQL: A relational database for modern applications

#23

Post by endisneigh »

This bit:

> maladapted to modern cloud computing abstractions such as serverless, and is difficult to manage at scale.

Got me.

There’s little money in it but working in an infra role for a while now - I don’t really see rolling your own infra as becoming any easier which is so sad.

Re: Beyond SQL: A relational database for modern applications

#24

Post by Glyptodon »

briandilley wrote: post #22

I have yet to come across a replacement for SQL that makes it easier, or more concise, while also remaining feature rich. Not knocking this, but SQL is a pretty solid and time-tested technology for querying structured data. Alas, if we don't experiment then I guess we wont get better.

I think like 85% of the pain points could be solved by (a) allowing statements to start with a `from` clause, (b) some kind of shorthand for field sets, and (c) having some kind of syntax for returning some things as nested rows/objects. Without thinking deeply at all:

from users u join purchases p on p.user_id = u.id select u{defaults}, u[p{defaults} as purchases] limit 100 [purchases: 10]

returning rows that make `purchases` into a row-nested collection of up to 10 items instead of creating that many more overall rows and repeating the same user info multiple times.

Re: Beyond SQL: A relational database for modern applications

#26

Post by irrational »

chrnola wrote: post #19

I’m having a hard time understanding this line: “Developers cannot take advantage of the full power of the underlying database for fear that the complex, opaque nature of SQL query behavior will overwhelm their ability to understand how queries perform, and quickly address problems when they do come up.” What does that mean? Developers are somehow sacrificing database performance (“full power”) because they’re too sc…

Right? I’ve written tens of thousands of sql queries, some of which were thousands of lines long. I can’t remember ever feeling overwhelmed. It’s just a tool. If you are feeling overwhelmed by a tool, just practice more.

Re: Beyond SQL: A relational database for modern applications

#27

Post by paulddraper »

resharpe105 wrote: post #13

I have to disagree with the following paragraph: “SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure that is aligned with how the application needs to consume the result. ORMs solve this partially at best at the cost of hiding the capabilities of the underlying database. They also obscure the structure of gener…

I agree with the sibling; the problem is that requires that you shoehorn all your rich data types to JSON.

Re: Beyond SQL: A relational database for modern applications

#28

Post by talldatethrow »

edmundsauto wrote: post #16
talldatethrow wrote: post #3

I wrote my first self taught LAMP based miniSaas a few years ago. It has 34 paying companies using it with about 400 users total daily. I want to write another soon. A free webapp saas type for consumers let's say. Is there a reason I should learn this product instead of just continuing with modern mysql methods that seem to work and seem secure enough?

Is your primary objective to expand your experience and knowledge, or is it to ship product that delivers user value?

Obviously the answer is to deliver user value.... But at the same time, better performance is valuable to a user. So if this new, whatever it is I don't even know, will perform better at an atleast noticable metric, then it does deliver value to the user. If all it does is make MY life easier, then it's basically worthless to me IMO.

Re: Beyond SQL: A relational database for modern applications

#29

Post by sgarland »

rtpg wrote: post #20

One of my side ideas is to write a postgres plugin offering an alternative syntax for queries, but one that requires you to name the index you use (or to explicitly mention a table scan). I do understand the value of SQL + the planner for adhoc querying. But so many times I find myself reworking SQL to hint at the planner to use certain indexes, or to add "spurious" filters to make sure an index is used (spurious for…

If the query planner doesn’t want to use an index, it’s either for a good reason, or your table statistics are woefully out of date.

Re: Beyond SQL: A relational database for modern applications

#30

Post by nextaccountic »

freels wrote: post #15
resharpe105 wrote: post #13

I have to disagree with the following paragraph: “SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure that is aligned with how the application needs to consume the result. ORMs solve this partially at best at the cost of hiding the capabilities of the underlying database. They also obscure the structure of gener…

I'm clearly biased, but at least in my experience, while this is technically true, you're still dealing with XML (and now JSON) shoehorned into a tuple-based context. In other words, there is still a (lossy) translation layer, it just happens to be in the RDBMS rather than in-app. Fauna's advantage here is that this way of structuring queries is deeply integrated with the language (and underlying wire protocol) itsel…

> In other words, there is still a (lossy) translation layer, it just happens to be in the RDBMS rather than in-app.

It's not lossy if your application can guarantee a json datatype roundtrip and the json is validated with jsonschema (generated by your application)

In Rust it's something like this

https://serde.rs/ to do the data type json mapping

https://docs.rs/schemars/latest/schemars/ to generate jsonschema from your types

https://github.com/supabase/pg_jsonschema to validate jsonschema in your database (postgres). with this setup it's interesting (but not required) to also use https://docs.rs/jsonschema/latest/jsonschema/ to validate the schema in your application

Post reply on HN