Hacker News Reader

Comment by nerdponx | Hacker News Reader

Carefully designing your application around an underpowered database is almost surely more complicated than just paying for a more powerful database.

We're not talking about K8s or sharding. We're talking about adding more cores and RAM to the single database node that they're already using.

Imagine how much easier the backend dev's life would be if they could just write SELECT FROM JOIN WHERE like everyone else, and not have to pore over query plans and design/implement/test a bunch of custom joining routines. This path sounds like a high-effort artisanal approach to something where it doesn't seem warranted. It's penny-wise and pound-foolish in exactly the way you (very nicely) described.

View on HN

It's true, but its great experience for future things when the costs actually matter - I cut my teeth at a biz that refused to pay more for database hardware and now my performance skills pay the bills at much nicer companies.

Surely it's great for you as the developer to get paid extra to learn transferable skills.

That's not necessarily true of the business.

Absolutely, I did not feel it as a positive at the time and recommended not that much more money for significantly better utilization of human time, but you take what you can get with intractable CEOs.

Imagine how much easier the frontend dev's life would be if they could just demand whatever horrifying schema they want, and it would be delivered to them. Oh wait, that's GraphQL, and it worked as well as it sounds.

I am begging people to learn SQL; it is not a hard language, and it hasn't changed in decades.

any good book ?

For beginner learning? https://sqlbolt.com/ is a decent place to start.

Intermediate and advanced too, if you can, that would be lovely.

https://modern-sql.com/ has some info about more recent additions to SQL to make life easier/write higher level or more composable queries.

Once you have the basics of SQL down (like how to write a query), you want to understand what the database actually does with your queries, so you can predict what the query plan "ought to be"/what you want, and you can read the query plans to try to understand why you did or didn't get the plan you expect.

https://use-the-index-luke.com/

And then once you understand the fundamentals, your database's manual is the place to go. Especially different index types (including their internals!) and what kinds of queries they support. The above link goes into depth about b-trees, but there are other types, and you can use b-trees as a reference point to contrast with others.

https://www.postgresql.org/docs/current/index.html

thank's a lot

I bought https://theartofpostgresql.com/ few years a go. It goes more into intermediate/advanced category and I have been quite happy with it.

I was fortunate to have a Database Basics course in the university that was 80% database schema design and 20% SQL queries and indexes. Reasoning for such a split was that fixing a bad database schema is much harder than fixing bad queries.

thanks too

Reply on news.ycombinator.com