Seriously. Data types -- surely anyone who has used any SQL database knows their internal data types? Although, true, I have seen a few odd table schemas in my time. Mainly in SQL Server databases it has to be said.
Another thing I've noticed more recently - rails developers who know almost nothing about how the database works. Like they might barely be able to write a inner join among 3 tables; left/right joins flummox them entirely. This is by no means universal, but I've encountered it several times in the last year, enough to be a trend in my mind.
As to CHAR vs VARCHAR -- well, is it fixed length or constantly changing? The clue is in the name. And CHAR is usually up to 50% faster on overhead and VARCHAR uses padding which can be a huge waste of space. They should just know this.
Then, SQL Joins are plain English and should be easily visualised in the abstract (it does help if you can see the data in front of you though, I can't deny).
Date vs Time is something I am finding confuses lots of people. Precision as well.
It's CHAR that pads with spaces, not VARCHAR.
I think a lot of people my age are similar. We aren't 30 year olds who have had 5 years of actual SQL experience before ORMs got popular. We've had maybe 1 year or so and then after that its all just ORM.
Personally I use Django. When it comes time for me to perform a query that might require multiple inner joins, a group by, and aggregates I will often write the query by hand. This allows me to figure out the requirements of the query. From there I figure out how to accomplish that with the ORM.
I think more people should take this approach. It would help people understand what it is they are doing with the database.
EDIT: That being said, having an ORM do exactly what you want can be like pulling teeth sometimes. I must say, I'm not fully sold on the ORM.
In the Python world, I like SQLAlchemy. It performs well, it's fairly well documented (improving, though I've had to read source code to figure out options before), and it's not tied to a web framework, the way I believe Django's is.
The classic CF in rails is a form that ultimately deals with > 1 table. Multi-table forms are a pain for everyone, but with a bit of database juju you could disguise the complexity with, say, an updateable view.