I was horrified how little I knew about the depths of SQL, and how useful the arcane corners really are. Should I be scheduling more SQL sessions at OSCON on the assumption that most everyone else is just as ignorant as me, or would that be a waste of time?
I feel that OSCON is not the place for a set of SQL talks. There are so many differences between the DBMS vendors SQL versions that it would be either a) very general (and therefore not too usefull) or b) vendorspecific.
A tutorial on how to use eg MySQL with DBI could be much more interesting and would hit the target audience better.
With SQL, you can get very far with limited knowledge. In my experience, for general database
usage, you don't need to know much beyond natural
joins (maybe left joins, sometimes) and basic
agregate functions to get many jobs done.
I guess it's kind of like Perl in that way.
Is there a way to teach "SQL"? Is there a fully (and only) ANSI-SQL compliant RDBMS that can be used as a teaching system, without having to
learn vendor-specific details? While such a system might be less useful in the real world (v
With SQL, you can get very far with limited knowledge. In my experience, for general database usage, you don't need to know much beyond natural joins (maybe left joins, sometimes) and basic agregate functions to get many jobs done
I agree.
There are times when you need stored procs and triggers in your database. But those are easily part of the 80% of SQL that's necessary about 20% of the time. You can get around the need for those features by using DBI or some other programmatic interface into the
Something on "dark corners", "cool tricks" and/or "common pitfalls" would be great.
Speaking of sessions -- Friday looked really light last time I peeked at the schedule. I know that people often filter out during the afternoon, but the sessions themselves haven't historically thinned out that much. For 2003, it looks like *all* of Friday is thin. Is that just a result of the schedule being so preliminary?
Hum... SQL.... (Score:1)
Nah... (Score:1)
A tutorial on how to use eg MySQL with DBI could be much more interesting and would hit the target audience better.
hmmm (Score:2)
Isn't it better to actually remain ignorant of said arcane corners? ;)
-- Robin Berjon [berjon.com]
How much SQL is enough? (Score:1)
With SQL, you can get very far with limited knowledge. In my experience, for general database usage, you don't need to know much beyond natural joins (maybe left joins, sometimes) and basic agregate functions to get many jobs done. I guess it's kind of like Perl in that way.
Is there a way to teach "SQL"? Is there a fully (and only) ANSI-SQL compliant RDBMS that can be used as a teaching system, without having to learn vendor-specific details? While such a system might be less useful in the real world (v
(darren)
Re:How much SQL is enough? (Score:2)
I agree.
There are times when you need stored procs and triggers in your database. But those are easily part of the 80% of SQL that's necessary about 20% of the time. You can get around the need for those features by using DBI or some other programmatic interface into the
Yes to SQL sessions (Score:1)
Speaking of sessions -- Friday looked really light last time I peeked at the schedule. I know that people often filter out during the afternoon, but the sessions themselves haven't historically thinned out that much. For 2003, it looks like *all* of Friday is thin. Is that just a result of the schedule being so preliminary?
Re:Yes to SQL sessions (Score:2)
--Nat