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

51–60 of 61 posts

Re: Beyond SQL: A relational database for modern applications

#51

Post by 3cats-in-a-coat »

abenga wrote: post #46
3cats-in-a-coat wrote: post #38

Earlier quoted context omitted.

I agree with what you say. On the other hand, it shows how when something gets popular enough it gets stuck in place, unable to progress slowly towards better, because we keep calling it good enough and all marginal improvements that accumulate to something significant over time are rejected. And this friction can be a significant problem, because it can cause systems to die overtime by being suddenly replaced, disru…

Additions and improvements to SQL standards happen all the time though. My favourite rdbms drops a new version every few months with exciting new features. This sounds more like the slow and steady improvement you speak of than all these proprietary newfangled languages that show up every few months, never to be heard from again.

Not quite. SQL and the web are examples of standards that evolve by accumulating cruft. They try to address more and more unaddressed edge cases by constantly adding new slightly different ways of doing the same thing without addressing the core problems that cause this complexity in the first place. Evolution is not about adding features alone. It’s about also removing and changing features. If you read carefully the linked site, it offers way, way more than a fancier way to do a SELECT.

The SQL standard is also adding features that go ignored about most SQL databases, because the client libraries won’t support to them and they’re out of sync with the server and so on and so on.

Entropy is eating SQL and the web.

Re: Beyond SQL: A relational database for modern applications

#52

Post by abenga »

3cats-in-a-coat wrote: post #51
abenga wrote: post #46

Earlier quoted context omitted.

Additions and improvements to SQL standards happen all the time though. My favourite rdbms drops a new version every few months with exciting new features. This sounds more like the slow and steady improvement you speak of than all these proprietary newfangled languages that show up every few months, never to be heard from again.

Not quite. SQL and the web are examples of standards that evolve by accumulating cruft. They try to address more and more unaddressed edge cases by constantly adding new slightly different ways of doing the same thing without addressing the core problems that cause this complexity in the first place. Evolution is not about adding features alone. It’s about also removing and changing features. If you read carefully th…

Be that as it may, every time I see a new database product I open the page, and if it doesn't support SQL, more often than not I never think about it and don't think about it again. I am never going to invest in some proprietary query format for marginal gains over SQL, seeing as I'm yet to run into a situation where having to write SQL precludes solving a problem I had. I really don't want data stores to adopt the frenetic rate of change seen in other areas of the field (like JS, shudder).

I think Postgres does an excellent job staying up to date with ANSI SQL; all other implementations (other than sqlite) are largely irrelevant to me.

Re: Beyond SQL: A relational database for modern applications

#53

Post by 3cats-in-a-coat »

abenga wrote: post #52
3cats-in-a-coat wrote: post #51

Earlier quoted context omitted.

Not quite. SQL and the web are examples of standards that evolve by accumulating cruft. They try to address more and more unaddressed edge cases by constantly adding new slightly different ways of doing the same thing without addressing the core problems that cause this complexity in the first place. Evolution is not about adding features alone. It’s about also removing and changing features. If you read carefully th…

Be that as it may, every time I see a new database product I open the page, and if it doesn't support SQL, more often than not I never think about it and don't think about it again. I am never going to invest in some proprietary query format for marginal gains over SQL, seeing as I'm yet to run into a situation where having to write SQL precludes solving a problem I had. I really don't want data stores to adopt the f…

Consider the paradox. You don’t care about proprietary standards, but you use a database that stands mostly alone in implementing the standards you track, and also it has many proprietary extensions on its own.

I’m curious if PG supports heterogenous nested results (data trees) this one of the biggest omissions from the standard on all dbs I use to the point I can’t use this at all.

Re: Beyond SQL: A relational database for modern applications

#54

Post by resharpe105 »

Glyptodon wrote: post #24
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 `…

You can easily do nested rows/objects in sql.

E.g.in postgres:

SELECT u.*, ( SELECT JSON_AGG(p) FROM ( SELECT p.* FROM purchases p WHERE p.user_id = u.id LIMIT 10 ) p ) AS purchases FROM users u JOIN purchases p ON p.user_id = u.id GROUP BY u.id LIMIT 100;

Starting queries with from - what is the benefit of that beside personal preference?

And you can simply use a cte or a view instead of a field set.

Re: Beyond SQL: A relational database for modern applications

#55

Post by bob1029 »

setr wrote: post #50
digdugdirk wrote: post #44

Earlier quoted context omitted.

That seems super interesting. Do you have any book/article recommendations that dive into this mindset?

The set theory? Look up relational algebra. These discussions get murky because people always conflate SQL the language with the underlying relational algebra, so it’s near impossible to criticize the language alone — like exactly in this case. It also gets conflated with the RDBMS engine, which doesn’t help either. The article specifically calls out issues with the language, and specifically seeks to maintain the al…

> Codd created something beautiful; ibm created something significantly less so.

IBM made it practical to apply these beautiful ideas to boring-ass business.

Without IBM, we wouldn't be talking about SQL today.

Re: Beyond SQL: A relational database for modern applications

#56

Post by panick21_ »

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.

Look at Datomic, you can have Datalog, Pull based access and you can use programing languge functions directly in the query all in one.

Typical pattern us you find a list of ids and pull on them with a particular view that you want them in.

Re: Beyond SQL: A relational database for modern applications

#57

Post by edmundsauto »

talldatethrow wrote: post #28
edmundsauto wrote: post #16

Earlier quoted context omitted.

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.

How much of a problem is performance right now, has anyone mentioned it to you? Has it gotten worse?

I often think about perf as thresholds. It's not totally accurate but if you have reasonable perf, generally going to lightning turbo / "Please the HN crowd because we hate bloat" isn't going to move the needle.

Re: Beyond SQL: A relational database for modern applications

#58

Post by talldatethrow »

edmundsauto wrote: post #57
talldatethrow wrote: post #28

Earlier quoted context omitted.

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.

How much of a problem is performance right now, has anyone mentioned it to you? Has it gotten worse? I often think about perf as thresholds. It's not totally accurate but if you have reasonable perf, generally going to lightning turbo / "Please the HN crowd because we hate bloat" isn't going to move the needle.

With 400 daily users in the CRM, mysql is not a problem at all. The only problem I have is loading huge tables sometimes without using pagination, but that's from a connection speed problem to the user not a mysql problem. Sometimes the table makes it towards 10+ megabytes and thats a bit goofy.

My question was more based on should I learn the new tech, or any new tech, if I'm now building something I hope will have atleast several thousands daily active users.

Deep down I know the answer. It's pretty obvious mysql won't have problems even for a million users for most types of sites.

Re: Beyond SQL: A relational database for modern applications

#59

Post by edmundsauto »

talldatethrow wrote: post #58
edmundsauto wrote: post #57

Earlier quoted context omitted.

How much of a problem is performance right now, has anyone mentioned it to you? Has it gotten worse? I often think about perf as thresholds. It's not totally accurate but if you have reasonable perf, generally going to lightning turbo / "Please the HN crowd because we hate bloat" isn't going to move the needle.

With 400 daily users in the CRM, mysql is not a problem at all. The only problem I have is loading huge tables sometimes without using pagination, but that's from a connection speed problem to the user not a mysql problem. Sometimes the table makes it towards 10+ megabytes and thats a bit goofy. My question was more based on should I learn the new tech, or any new tech, if I'm now building something I hope will have…

If your high end user estimate is in the thousands, scaling is less of an issue. If users haven't mentioned frustration with latency, it's probably not a problem.

That said, you still have to feed your creativity and curiousity. I try to carve out time for "not totally necessary but skill growth and potentially impactful" time.

Re: Beyond SQL: A relational database for modern applications

#60

Post by talldatethrow »

edmundsauto wrote: post #59
talldatethrow wrote: post #58

Earlier quoted context omitted.

With 400 daily users in the CRM, mysql is not a problem at all. The only problem I have is loading huge tables sometimes without using pagination, but that's from a connection speed problem to the user not a mysql problem. Sometimes the table makes it towards 10+ megabytes and thats a bit goofy. My question was more based on should I learn the new tech, or any new tech, if I'm now building something I hope will have…

If your high end user estimate is in the thousands, scaling is less of an issue. If users haven't mentioned frustration with latency, it's probably not a problem. That said, you still have to feed your creativity and curiousity. I try to carve out time for "not totally necessary but skill growth and potentially impactful" time.

I happened to be sitting in front of a JavaScript book as you wrote that.

I finally opened it. I was always curious if I should learn js/node to replace PHP and maybe even get away from server side rendering in php. Right or wrong, from what I've read I think I can put that to rest for now. I see just as many issues with doing things in JS as PHP. Just spending a few hours of reading let my brain move on from that curiosity for now.

Good tip you gave. Thanks

Post reply on HN