I feel fairly confident that I can write SQL queries for basically any result set (On a well designed DB). But the project I am working on is close to breaking me (VERY bad DB design, in progress)
Also: I think knowing your way around triggers and such is quite important too though. I should learn them properly some day.
Triggers can be an absolute nightmare to debug, and basically impossible to retroactively determine why a particular trigger did or didn't fire.
I've had the displeasure of working with databases with triggers that fire other triggers, and all that logic should've been moved into the application itself. They're a powerful tool to have in your toolbox, but should be used sparingly, and should be kept as simple as possible.
I remember looking at a MS Dynamics AX database, not hugely complex by ERP standards with about 5000 tables, and realising it didn't use foreign keys. That was fun.
The same table stores: Addresses (primary, secondary), sex, names (up to 3), date of birth, what currency, and many MANY more values.
Yes, that's one table.
Also: Another table literally stores full tables in it. (Basically some kinda key with which to identify the subtable so you can select on it.)
Progress has no real concept of set based queries, instead it accesses all tables like a cursor.
And that's not even scratching the surface. The DB is bad and should feel bad. Just yesterday I went into a 2 hr rant about it with some people I often talk to.
Foreign keys, too, are a foreign concept to progress. But hey, work is work.
In some cases, we aren't in a position to normalize the database due to legacy situations.
However, one thing that could be done is to use views (maybe scoped in their own schema) to make the database look normalized (Facade the database). This would help with writing future SQL.
It is then possible to iteratively normalize the underlying tables by pointing legacy code at the normalized views until the denormalized tables are no longer in use. Finally, "convert" the views into tables and drop the denormalized tables.
Also: I think knowing your way around triggers and such is quite important too though. I should learn them properly some day.