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

SQLBolt – Interactive lessons and exercises to learn SQL

sqlbolt.com

Post reply on HN
Print view View original

41–50 of 87 posts

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#41

Post by moehm »

dragonwriter wrote: post #33
moehm wrote: post #31

Earlier quoted context omitted.

Quite the contrary, ORMs in general are less performant. Using ORMs boils down to two things, convenience and the ability to switch the underlying RDBMS. (For example all the OSS which says you can choose between MySQL, Postgres or SQLite.) But if you support all RDBMS you only can support the smallest intersection between them and can't use advanced features like CTE, window functions, JSON support etc.

> But if you support all RDBMS you only can support the smallest intersection between them and can't use advanced features like CTE, window functions, JSON support etc. That's not true at all, any more that it’s true of supporting all browsers with JS. You can use the advanced features where available, and implement logically (if not performance)-equivalent functionality using more basic functions where the advanced…

Yeah, sure, you can always write raw SQL queries, but that has nothing to do with your ORM, does it?

I was talking about ORMs in general, not about the programmer in particular. So yes, you are right that if you have enough engineering resources you can support everything. But most ORMs don't help you with this, so it is not a feature of ORMs. You can always bypass it though.

The comparison with JS doesn't fit realy well, because JS is the tool you have to use. You don't have to use ORMs, plain SQL works fine as well.

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#42

Post by blowski »

Cthulhu_ wrote: post #22
blowski wrote: post #14

Earlier quoted context omitted.

I’m very guilty of all those sins. Select all, then use array map, reduce and filter in the app code. I could draw a line in my life where I discovered window functions.

If the dataset is big enough, those operations actually do make sense because they can be translated to e.g. a Hadoop job - map / reduce / filter are all operations that don't depend on the sorting of a dataset, so in theory the dataset can be sharded across many machines. Of course, that is a solution to a problem that people wish they had. Relational databases can run multi-million row queries in seconds, and then…

Exactly. I'm talking about the "select 5000 rows, serialize them to JSON, and send them over HTTP to the browser, only to render them in a table that never changes" type code.

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#44

Post by snorremd »

seer wrote: post #18
blowski wrote: post #9

My favorite book for learning SQL is “The Art of PostgreSQL”. https://theartofpostgresql.com/ I found the combination of real-world problems, general SQL advice, and the broad range of topics to be a really good book. It took my SQL from “the database is not much more than a place to persist application data” to “the application is not much more than a way to match commands to the database”. It’s amazing how much bes…

I'm slowly moving in that direction. Recently started using (pg-typed)[1] in our projects and its amazing, as it gives you the types from the database into typescript, and not the "general types from tables", but the exact specific types for each individual query. Coupled with the same thing going the other direction where we get types from our api contracts (OpenAPI/Swagger) with (laminar)[2] means that our app is v…

The blog post[1] by the author about ORMs was what convinced me to purchase the book. I've had too many discussions with colleagues and tech friends struggling with N+1 problems and processing too much stuff in the application when they use mainstream ORMs to think it is a good idea. ORMs make the regular CRUD stuff simpler, but seem to make some more complex queries and transactions harder. There also seems to be an impedance mismatch between SQLs relational model and the OOP object relationship model.

Edit: I know there are ways to avoid N+1 problems with ORMs, but it seems to more easily sneak into code when your SQL queries look just like your application level code and you could easily enumerate over some SQL result, perform some action, and think that it builds an efficient query.

I've recently been working with a hobby project where I use the Clojure HoneySQL[2] library which essentially lets you build SQL queries as you normally would, but in Clojure's EDN syntax. It treats SQL queries as data. You can super easily evaluate them to get the resulting raw SQL query strings. There is no magic behind it and it encourages you to use the full power of your db.

[1] https://theartofpostgresql.com/blog/2019-09-the-r-in-orm/ [2] https://github.com/seancorfield/honeysql

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#45

Post by mongol »

Zababa wrote: post #29
stouset wrote: post #13

Earlier quoted context omitted.

I haven’t read this yet but I love your take. Far too often do I see developers doing analytics by slurping an entire table across the network and performing calculations on it in the application. Of course it appears to work in development with tens of kilobytes of records and a local database, but as soon as it’s deployed to production it unleashes chaos. I consider myself very good at SQL but I do prefer to use OR…

One argument I've often heard is that since it's easier to scale your application compared to your database, pushing the calculations on your application is a way to get a better scalability in the long term. I wonder how true that is though.

Depends a lot. You need to consider the requirements more in detail, and especially if we are considering reads vs writes, and also what are the methods to write the data that needs scalable reads.

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#46

Post by wirthjason »

blowski wrote: post #40
wirthjason wrote: post #36

Earlier quoted context omitted.

Holy smokes, $100?!?! You’re not kidding! I’m always willing to buy technical books. I think it’s valuable to have material from different authors because they each have different perspectives and styles. E.g. CLRS vs Sedgewick vs Skiena. I also like to support the authors. However I’ll take a hard pass at this one. My ability to level up is rarely due to the quality of the material, it’s more a function of how much…

I look at it that I spent $100 on this book, and got a $20K payrise. At that order of magnitude, the difference between spending $10 and $100 didn't matter.

You didn’t get the pay raise because spent $100, you got the pay raise because you spent hours, days, months.

It’s time, not money, you are spending.

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#48

Post by gmac »

seer wrote: post #18
blowski wrote: post #9

My favorite book for learning SQL is “The Art of PostgreSQL”. https://theartofpostgresql.com/ I found the combination of real-world problems, general SQL advice, and the broad range of topics to be a really good book. It took my SQL from “the database is not much more than a place to persist application data” to “the application is not much more than a way to match commands to the database”. It’s amazing how much bes…

I'm slowly moving in that direction. Recently started using (pg-typed)[1] in our projects and its amazing, as it gives you the types from the database into typescript, and not the "general types from tables", but the exact specific types for each individual query. Coupled with the same thing going the other direction where we get types from our api contracts (OpenAPI/Swagger) with (laminar)[2] means that our app is v…

Anyone who's interested in pgtyped may find this library comparison helpful: https://phiresky.github.io/blog/2020/sql-libs-for-typescript...

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#49

Post by mritchie712 »

qwerty456127 wrote: post #21

SQL is both slightly ugly (which I attribute to the historical decision to use natural language words instead of the mathematical symbols of the relational algebra notation - the symbols make the expressions more readable once you learn them) and very beautiful. I'm sad most of the people have forgotten it and prefer to use ORMs today. Most often (except when coding a stupid low-feature phonebook/todolist tutorial) i…

A little more detail on the history:

https://twitter.com/mike_seekwell/status/1412777805759365120

Re: SQLBolt – Interactive lessons and exercises to learn SQL

#50

Post by simonbarker87 »

qwerty456127 wrote: post #21

SQL is both slightly ugly (which I attribute to the historical decision to use natural language words instead of the mathematical symbols of the relational algebra notation - the symbols make the expressions more readable once you learn them) and very beautiful. I'm sad most of the people have forgotten it and prefer to use ORMs today. Most often (except when coding a stupid low-feature phonebook/todolist tutorial) i…

I had to work with TypeORM at my last place and hated it. Prior to that I was at a place with a lot of hand written SQL and while that wasn’t perfect it was much easier to work with
Post reply on HN