I like the idea of it targeting developers but aren't most developers going to end up using an ORM in the end? For example SQLALchemy in Python and ActiveRecord in Rails. Is the book a ton of SQL examples or general theory? Most of my day to day database activities as a web developer are creating good indexes, data modeling and setting up queries with an ORM.
That's a good question. I don't use an ORM, but you do, so that tells us that 50% of developers use an ORM ;-)
Does anyone have any stats on what percentage of developers use an ORM?
Looks interesting, wish I could "preview" before buying. Thankfully before venturing out on my own in the web development world, I was a member on a small business analytics team were we would all regularly write 3+ page SQL queries for reports. Sometimes they's take days to run. It was awesome and horrifying all at once but a good experience nonetheless and has allowed me to do what I do today.
I see in the FAQ that Tapoueh promises to refund anyone who isn't satisfied for any reason.
Email for updates being a foot in the door for further communications is pro forma and legally regulated. I think you're unnecessarily suspicious.
Even if it isn't nefarious, it's often unwanted. I usually turn around if I have to provide my email to see some sort of whitepaper or sample because it means I will have to later unsubscribe from whatever email list I was put on and hope they don't share the list with others (which happens, often).
Whenever someone asks for an email, I just type lalelu@yopmail.com, and then I go to http://yopmail.com/lalelu and click the activation link.
Just FYI, in the "The Dead Tree Edition" section, "professionally" is spelled wrong: A professionnally printed paperback of 332 pages, with the same content.
Thanks, fixed now!
"The Full Edition comes with the eletronic book package and an archive with a PostgreSQL dump file ready to be restored in your own instance, plus all the 265 queries as separate files for you to run and edit!"
I've been wondering for a while about the practicalities of using postgres as a replacement or near-replacement for a traditional backend - does anyone have any opinions on how far it's wise to go with this (postgres-only? authentication? direct connections from the client?) and/or how feasible that kind of thing is?
This depends a lot on the usecase. You have to consider things beyond the simple serving of requests, things like rate-limiting, caching, logging, event tracking, for example. About a year ago I designed a system for a client that was just Postgres with a Go http frontend. Go was used to handle http requests and responses, to translate the API from http to postgres functions/views, and serve the response straight fro…
Sounds like client-server development on oracle 20 years ago...
"The Full Edition comes with the eletronic book package and an archive with a PostgreSQL dump file ready to be restored in your own instance, plus all the 265 queries as separate files for you to run and edit!" eletronic is also a typo.
Fixed now. I really should have had my reviewer work on the website too, not just the book itself. Thanks guys!
I like the idea of it targeting developers but aren't most developers going to end up using an ORM in the end? For example SQLALchemy in Python and ActiveRecord in Rails. Is the book a ton of SQL examples or general theory? Most of my day to day database activities as a web developer are creating good indexes, data modeling and setting up queries with an ORM.
That's a good question. I don't use an ORM, but you do, so that tells us that 50% of developers use an ORM ;-) Does anyone have any stats on what percentage of developers use an ORM?
IMO an ORM is not a substitute for knowing SQL, much less studying the actual database.
To me, an ORM is a tool that allows someone that knows SQL to write statements they would write by hand using business-level vocabulary.
Also, you have to be savvy enough to know when you are hitting the max expressiveness of the ORM and need some powerful SQL you better write by hand. Active Record certainly provides API for that, and it is an API you are supposed to leverage when the circumstance arises (Rails team over here).
I like the idea of it targeting developers but aren't most developers going to end up using an ORM in the end? For example SQLALchemy in Python and ActiveRecord in Rails. Is the book a ton of SQL examples or general theory? Most of my day to day database activities as a web developer are creating good indexes, data modeling and setting up queries with an ORM.
The book covers some theory when it's needed and comes with lots of practical examples, all using real world data sets to make them easier to understand and relate to.
Using an ORM and how to best integrate “raw SQL” in your code is also discussed, and data modelling gets its own chapter too. I think you will like it!
The “dead tree edition.” Good play, sirs. I’m going have to get that one though. I can’t seem to focus/finish when reading educational books on my kindle or in PDF form. I like the “turn thousands of lines of code into queries”... I can’t count the number of times I’ve seen application code doing something a query could do either to appease an ORM or because a backend engineer wasn’t fluent in intermediate SQL.
Yeah... i'm totally guilty of abusing the 'python can do it' hammer instead of leveraging the DB. Just last week i looked at an old snippet of code that was essentially a 'query data, load in python, process, shove back in postgres' workflow. I was like, AHA i know better. spent 15 mins figuring out how do accomplish the same thing in the database. Now that shitty code is gone, replaced with 1 SQL statement that runs in seconds, compared to tens of minutes!