The nice thing about SQL is that it doesn't take very long to learn how to use it and then it's incredibly useful any time you have a database to interact with. I think all novice programmers should take a crack at it.
Learn SQL, dammit
51–60 of 118 posts
Re: Learn SQL, dammit
#52I once interviewed a guy with a Masters in computing (of some sort, I forget) who didn't know SQL. He'd been developing for years, but lived entirely in .NET land and just used ORMs. Absolutely crazy.
I have a PhD in computing (of some sort, I forget) and I know about 3 SQL commands. I've been developing for decades, and I never need to interact with databases. Like everyone in my field of research, I keep my data in text files.
Re: Learn SQL, dammit
#53For a while I used to ask interview candidates to explain the difference between WHERE and HAVING, to see if they'd ever done anything beyond the basics. I'm still not sure if that's too hard, but people who could answer it did tend to do much better in the rest of the interview as well.
It's sad but this difference, although completely fundamental to SQL, is seen as "advanced" by most devs that I know. They would have no clue as to how to answer...
Order of execution is a great second stop on the road to SQL, after learning what all of the words mean.
Re: Learn SQL, dammit
#54Earlier quoted context omitted.
it's really not as much about the querying (though there is a lot of time-saving automation to be had there) as it is about integrating the data in your object model with the tuples being shuttled to/from the database. Like, at what point do you get sick of writing redundant "INSERT INTO " over and over again? Are there really people who still don't see the time-wasting, code-cluttering repetition in that?
I'm still amazed that there are developers who would rather spend more time maintaining/debugging/optimizing ORM code in a mature app that just learning a simple INSERT statement.
Because in my experience, the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?), and the "optimizing" step hasn't been an issue for the traffic our sites get.
Re: Learn SQL, dammit
#55A class of query I love that scares off a lot of developers is a correlated sub-query, where the subquery references a value from the outer query. For example, finding all employees with at least one assignment: SELECT * FROM employees e WHERE EXISTS (SELECT 1 FROM assignments a WHERE a.employee_id = e.id) For a while in Oracle this was a lot faster than IN/NOT IN. I'm not sure if that's still the case, or if it's tr…
I think IN is equally fast in Oracle, or at least it was when I was working with 10.2.
In Postgres, it appears that this does the same thing as IN.
Re: Learn SQL, dammit
#56A class of query I love that scares off a lot of developers is a correlated sub-query, where the subquery references a value from the outer query. For example, finding all employees with at least one assignment: SELECT * FROM employees e WHERE EXISTS (SELECT 1 FROM assignments a WHERE a.employee_id = e.id) For a while in Oracle this was a lot faster than IN/NOT IN. I'm not sure if that's still the case, or if it's tr…
Why would you ever want to use such a horrible statement instead of using an inner join? scope :with_assignments, joins(:assignments) (or :assignment, depending on how your association is defined)
OP's query is not the same as an inner join; it will only return each employee only once while your query will return each employee for every assignment it is associated with.
Re: Learn SQL, dammit
#57The main point that one should know SQL as much as possible before using ORMs, I agree with fully. The point that applications should be written by quick-prototyping with an ORM, then replacing the ORM entirely with raw SQL, I could not disagree with more. Since he is using my own ORM (SQLAlchemy) as his example, I'd like to point out (as many of you know I always do) that SQLAlchemy's entire approach is one of expos…
This is very important. Any time you build a bike with training wheels, you need to build in a way to take the training wheels off. Otherwise, at some point the solution is to not make faster training wheels, but discard the bike entirely.
Is C training wheels on assembly?
Re: Learn SQL, dammit
#58How do you optimize your system if you don't understand the queries that the ORM generates?
How can you have any pudding if you don't eat yer meat?
Re: Learn SQL, dammit
#59Learn caching, dammit
Throwing caching at poorly written database code is exactly like when parents tell their children to tidy their room and then they shove everything under the bed. You can only do that for so long, at some point you need to clean that room up.
Re: Learn SQL, dammit
#60Everyone uses an ORM. You use a well known, documented, and supported ORM, or you're writing your own wether you realize it or not.
Don't believe me?
1. Do you have objects? 2. Do you have relational data?
There's the O and the R. How do you get them together? That's where the M comes in. You use a library that knows how to do the M, or you do your own M with a bunch of getters and setters, for loops and case statements.
Eventually, any little change to the database becomes a regression nightmare.
Once you find yourself saying "I know, I'll build a code generator to create these DAOs", that's when you should finally realize you should have used a real ORM. Sadly, many people still won't get it at this point and will go ahead with the code generator.