> For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases.
This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory. You can have a relational database that does not use SQL at all.
> if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying.
I agree with this. If you want to hire someone who understands the inner nuances of, say, MySQL then it may be a good question. This is quite a bit different to understanding relational databases though – one is theory, one is application.
No, it's not like that at all. RoR is a very specific application, if you can't write a controller then you probably don't know RoR, but it doesn't say you don't know programming in general.
Yes, you can have relational database that doesn't use SQL at all - how many of those are around and popular though? There are some, but not many. What are the chances that you worked with a lot RDBMS, yet never encountered SQL even at the basic level, and it is not immediately evident from your resume, which still says "SQL"? But OK, if that's the situation, you can say "you know, I worked with non-SQL relational databases, and let me tell you about this cool thing I've done that is way better than SQL JOIN can do" - and that might be fine too. Usually though the case is just that people inflate their resumes and think they won't be called out on it. It's very unpleasant because when you interview somebody whose resume looks good, you unconsciously plan that you'd get a great addition to your team - and then you discover he doesn't even know joins... Bummer.
BTW, inner join has nothing to do with MySQL inner nuances - it exists in virtually any SQL implementation out there AFAIK.
This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory. You can have a relational database that does not use SQL at all.
> if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying.
I agree with this. If you want to hire someone who understands the inner nuances of, say, MySQL then it may be a good question. This is quite a bit different to understanding relational databases though – one is theory, one is application.