4 ms·

Can you recommend some resources to achieve (b)? Just basic stuff without going full guru on every little detail. Or do you just mean using indexes basically?

Can you recommend some resources to achieve (b)? Just basic stuff without going full guru on every little detail. Or do you just mean using indexes basically? I'm just not sure how many unknown unknowns I have wrt sql.

Pamar 4y ago
(I am Not the OP) Not exactly from 0, maybe, but I strongly suggest this book: https://www.oreilly.com/library/view/the-art-of/0596008945/ https://www.oreilly.com/library/view/the-art-of/0596008945/
- RheingoldRiver 4y ago
  If you're really starting out from square 1, I might read this book first: https://www.amazon.com/Database-Design-Mere-Mortals-Anniversary/dp/0136788041 https://www.amazon.com/Database-Design-Mere-Mortals-Annivers... (although I read an earlier edition). The Art of SQL is a great book, but I wish I'd read something a bit...easier...first, lol. I struggled with it.
  - Pamar 4y ago
    Yeah well, I am old school (or at least old) so I had already a good grasp of SQL, but I think the book is good because it explains overarching concepts very well.
gen220 4y ago
The gist is: 1. Trace your application, so you know which query is running slowly in production. 2. Using this exact query, run `EXPLAIN ANALYZE` or whatever your RDBMS equivalent is. 3. Read the output, see which step is taking the slowest. Use google to help. 4. Google-fu until you find out which index might help you. Over time, (3) and (4) requires less and less Google, because there's really only a few common cases that give you 100% of the speedup in 80% of cases. Once you know this path to improvement exists, it's trivial to progress down it habitually. The `EXPLAIN ANALYZE` output looks like Greek at first, but quickly becomes as familiar to parse as a compiler error, etc.
- zasdffaa 4y ago
  DB 'expert' here - agree completely. It's about profiling then banging your head against it and learning more from books/the docs/web. That's really it.
wswope 4y ago
The details depend heavily on what specific database you’re working with, but in broad strokes, you’ll want to know: indices, query plans, when and where to cache expensive computations, every f—- word of your DB manual’s chapter on concurrency control, and the fastest method(s) for yeeting data in and out from your language/toolkit of choice.

Pamar 4y ago

(I am Not the OP) Not exactly from 0, maybe, but I strongly suggest this book: https://www.oreilly.com/library/view/the-art-of/0596008945/ https://www.oreilly.com/library/view/the-art-of/0596008945/

RheingoldRiver 4y ago
If you're really starting out from square 1, I might read this book first: https://www.amazon.com/Database-Design-Mere-Mortals-Anniversary/dp/0136788041 https://www.amazon.com/Database-Design-Mere-Mortals-Annivers... (although I read an earlier edition). The Art of SQL is a great book, but I wish I'd read something a bit...easier...first, lol. I struggled with it.
- Pamar 4y ago
  Yeah well, I am old school (or at least old) so I had already a good grasp of SQL, but I think the book is good because it explains overarching concepts very well.

gen220 4y ago

The gist is: 1. Trace your application, so you know which query is running slowly in production. 2. Using this exact query, run `EXPLAIN ANALYZE` or whatever your RDBMS equivalent is. 3. Read the output, see which step is taking the slowest. Use google to help. 4. Google-fu until you find out which index might help you. Over time, (3) and (4) requires less and less Google, because there's really only a few common cases that give you 100% of the speedup in 80% of cases. Once you know this path to improvement exists, it's trivial to progress down it habitually. The `EXPLAIN ANALYZE` output looks like Greek at first, but quickly becomes as familiar to parse as a compiler error, etc.

zasdffaa 4y ago
DB 'expert' here - agree completely. It's about profiling then banging your head against it and learning more from books/the docs/web. That's really it.

wswope 4y ago

The details depend heavily on what specific database you’re working with, but in broad strokes, you’ll want to know: indices, query plans, when and where to cache expensive computations, every f—- word of your DB manual’s chapter on concurrency control, and the fastest method(s) for yeeting data in and out from your language/toolkit of choice.