3 ms·

TLTR: Understand and optimize relational databases (MySQL, PG) rather than introducing a new type of database (e.g., DynamoDB, Kafka, Redis) whenever issues ar

by west0n 3y ago

TLTR: Understand and optimize relational databases (MySQL, PG) rather than introducing a new type of database (e.g., DynamoDB, Kafka, Redis) whenever issues arise. Common mistakes: - Lack of indexes - Using ORM (generating too many SQL queries or inefficient queries that return all columns) Some suggestions: - Use relational databases where possible, instead of NoSQL - Use read-only replicas instead of Redis when applicable - Keep relational databases clean and data size small The author's message is: Hey, folks, if you don't have the ability to use relational databases properly, then your usage of Kafka and DynamoDB will certainly be a mess as well.

corytheboyd 3y ago
You can use an ORM and not explode the number of queries to infinity. I’ve never seen it in the wild, so I get the blanket ban. In theory though you COULD contain ORM usage behind an intentional data access interface. I can only really speak for Rails from my own experience, but it most certainly tries exactly 0% to get you to care about this problem. It encourages deeply nested, at all layers of abstraction, through class inheritance and all that garbage, unrestricted access to the database through a very powerful ORM. You end up tuning performance of queries that end up changing in a month because of this. It’s wild.
- cameronh90 3y ago
  I'm a big fan of SQLAlchemy. While not without its quirks, it lets you write relational-style queries, but in native Python, and automatically maps the result sets to objects. If you have N+1 issues with SQLAlchemy, you probably would have had them with your own custom-written SQL queries also.
- west0n 3y ago
  so I leaved Rails, lol
  - corytheboyd 3y ago
    Don’t blame you!
- cogman10 3y ago
  Yeah, this is why I generally just don't like ORMs. They often just leaky abstractions where you end up not only needing to know how the ORM works, but also SQL when you need to go back and fix the ORM. There are exceptions, like jooq, which try not to really be an ORM and instead are just a language extension to help write sql (funnily, being an even more leaky abstraction is preferable here :D)

by west0n 3y ago

corytheboyd 3y ago

You can use an ORM and not explode the number of queries to infinity. I’ve never seen it in the wild, so I get the blanket ban. In theory though you COULD contain ORM usage behind an intentional data access interface. I can only really speak for Rails from my own experience, but it most certainly tries exactly 0% to get you to care about this problem. It encourages deeply nested, at all layers of abstraction, through class inheritance and all that garbage, unrestricted access to the database through a very powerful ORM. You end up tuning performance of queries that end up changing in a month because of this. It’s wild.

cameronh90 3y ago
I'm a big fan of SQLAlchemy. While not without its quirks, it lets you write relational-style queries, but in native Python, and automatically maps the result sets to objects. If you have N+1 issues with SQLAlchemy, you probably would have had them with your own custom-written SQL queries also.
west0n 3y ago
so I leaved Rails, lol
- corytheboyd 3y ago
  Don’t blame you!
cogman10 3y ago
Yeah, this is why I generally just don't like ORMs. They often just leaky abstractions where you end up not only needing to know how the ORM works, but also SQL when you need to go back and fix the ORM. There are exceptions, like jooq, which try not to really be an ORM and instead are just a language extension to help write sql (funnily, being an even more leaky abstraction is preferable here :D)