All the Perl that's Practical to Extract and Report

SQL

gnat on 2003-04-02T05:12:24

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?

--Nat

Hum... SQL....

trachtenberga on 2003-04-02T06:27:19

I would be interested in SQL talks.

Nah...

htoug on 2003-04-02T09:09:45

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.

hmmm

darobin on 2003-04-02T12:16:50

Isn't it better to actually remain ignorant of said arcane corners? ;)

How much SQL is enough?

dlc on 2003-04-02T13:16:37

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 (vendors introduce non-standard features for a reason), it would make a great learning / teaching platform.

Re:How much SQL is enough?

ziggy on 2003-04-02T14:21:45

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 database. Sure, it's not a purist's solution, but hell, it gets the job done. Basic SELECT/INSERT/UPDATE/DELETE with joins and aggregates do most of what you need.

Before I saw an SQL tutorial on the arcane corners, I'd like to see an SQL tutorial on the nasty gotchas. Things like misformulating a join and getting a product of MxN rows instead of an intersection. Or perhaps a walkthorugh on 3rd normal form and how it actually helps (and how denormalizing a database actually makes things simpler).

Yes to SQL sessions

jnoble on 2003-04-02T14:41:25

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?

Re:Yes to SQL sessions

gnat on 2003-04-02T21:39:19

See latest blog entry for details. Thanks for reminding me to talk about this. I think we need to clarify it on the web site too ...

--Nat