[vax_11]

> if you used an RDBMS in a non trivial app

Depends on what you mean by "trivial".

You can use a database for most of the things most websites use them for without ever using a JOIN. It just takes application logic instead of SQL.

Sites like this aren't exactly heavy on the SQL. This site doesn't even use SQL. Something like Reddit or Slashdot would, but still wouldn't need JOINs.

> I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM.

You don't have to drop below it; you can go "above" it into the application layer.

> If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, [...] But then if you could do all that why would you look for a job?

Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!"

There are a lot of people who aren't "PhD millionaires" or famous open-source magnates and yet are vastly capable. A lot of them don't write joins. And a lot of people who CAN write joins can't do a bunch of other stuff.

You know what else PG doesn't do? CSS. He runs a website but doesn't use CSS or SQL.

So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X.

[plinkplonk]

"Depends on what you mean by "trivial". "

Anything that has more than say, 2 tables, is what I meant by "non trivial" ;-)

"Sites like this aren't exactly heavy on the SQL."

Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and.

I never said you had to use an RDBMS to make a useful website. But if I was hiring for an RDBMS backed website , and you claimed to have used an RDBMS "for years" you'd better damned well know the basics. No "I don't know how to do a join across two tables because I did it in the application layer" doesn't cut it. That is a really stupid explanation of your ignorance and blows a big hole in your supposed "experience" with RDBMS.

"You don't have to drop below it; you can go "above" it into the application layer."

Sure you don't have to drop below the ORM. But you'd better know how to and when to . I wouldn't trust a developer with an ORM who didn't know ultra basic SQL. And a join in an RDBMS is ultra basic - someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables (the OP's question was aa simple join across two tables) is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers). Is that possible? I guess, Is it probable? Not at all.

Besides, using an ORM and doing a join in the application layer (without knowing how to do a SQL join) is ... unusual ;-).

"Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!""

Well if the PhD applied for a job that needs SQL he'd better know how to use SQL (or learn - it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query? If the PhD couldn't do that and claimed he had lots of experience with RDBMS and then said he didn't know how to write a join, then I'd write him off as incompetent (and possibly a liar) for this job, irrespective of his degree, sure) .

" A lot of them don't write joins."

as long as they can write a join after claiming to have worked with RDBMS for ages ;-)

"So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X."'

The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage and you end up wasting a lot of time talking to incompetent people.

[vax_11]

> Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and.

Valid refutation. You can use an RDBMS without making use of most of its facilities, and indeed, that is the typical usage case.

You can easily have a non-trivial app which makes what you'd probably consider trivial usage of a database.

> someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers)..

You're mixing up "working knowledge of SQL" with "expert knowledge of RDBMSes". I agree I am nowhere close to an RDBMS expert. However, I can use SQL, which was the point of the original post.

> after claiming to have worked with RDBMS for ages

Something is wrong in your mental model of my description. I used MySQL for years, starting many years ago. I did not say I was an expert in RDBMSes, or used advanced functionality in any sense, and I said the join functionality was done at the application level. My usage of SQL was basic, but I have a working knowledge of it. If there's something I need but don't know, I can read the docs and do it.

> it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query?

Reading an SQL book doesn't mean you're going to recall the syntax, until you have written queries a number of times by hand. I agree it is not complicated. I do not agree that asking someone to write a JOIN tells you anything about WHY they can't do it.

> The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage

You'd probably filter out Pete Norvig, and Linus, and who knows how many other expert programmers, if you asked them to write an SQL join off the top of their head.

[plinkplonk]

"You're mixing up "working knowledge of SQL" with "expert knowledge of RDBMSes. I agree I am nowhere close to an RDBMS expert. However, I can use SQL, which was the point of the original post."

Hmm you seem to be laboring under a concept that to know how to join two tables you need to be an RDBMS "expert" and "working knowledge" is not sufficient.

On the contrary, if you can't join two tables with SQL, you don't have any "working knowledge of SQL". Neither can you "use SQL" worth a damn. Every answer you make exposes the hollowness of your supposed "working knowledge"!

"However, I can use SQL"

Sure, as long as you query single tables (and do joins "at the application level") ;-)

[vax_11]

> Hmm you seem to be laboring under a concept that to know how to join two tables you need to be an RDBMS "expert"

You're misreading. You kept bringing up the point of "expert" knowledge (e.g. in C and for-loops), or knowledge of RDBMSes, and saying you couldn't know X without also knowing Y.

As the question was about SQL, NOT RDBMSes or "expert"-level knowledge of SQL or RDBMSes, I pointed that out.

> On the contrary, if you can't join two tables with SQL, you don't have any "working knowledge of SQL".

Depends on what "can't" you're talking about. I can look it up and then do it. A lot of people don't remember the syntax. Obviously anyone with working knowledge CAN do a join; the question was whether they could tell you how to do it off the top of their head.

Even things you've used a lot, if you haven't used them recently, you'd likely slip up in an interview.

> Every answer you make exposes the hollowness of your supposed "working knowledge"!

Not really. I can make things work (hence "working knowledge") and look up what I don't know and use it right away.

I've been using in-memory databases and of course the equivalent of a JOIN is a basic function but it's not an SQL JOIN.