Re: Unknown SQL

>> In simplest terms, it's another case of people refusing to think in more >> than one fashion.  

> Yes, this is probably very true. Thinking in SQL compares to thinking in
> objects like eating with a spoon compares to eating with chopsticks.

Seems to be the case yes ... but is it too much ask of a professional to know the tricks of the trade (in this case a modicum of relational theory). How can anyone with some exposure to handling large amounts of data, escape the conclusion that you have to handle this data as proper sets, not as one object at a time, millions of times over?

Let the DBMS do your loops for you; it is orders of magnitude faster (no silly roundtrips), cheaper (no coders having to write and debug silly loops), safer (transactions) and more flexible (very general querying) than you can ever hope to achieve.

So, coming back to the 'thinking in more than one fashion' bit: I think it's more serious than that: using the wrong tools for the job is not professional and may costs clients/consumers/employers time and money.

> Typically we do program with objects, though.

Well, I agree that there is a tension between objects and relations. Objects are useful/essential for application code; relations are useful/essential for large-scale data management. In my experience, having a (or several) object layer(s) (or an 'object-relational mapping') around an RDBMS goes a long way towards resolving this. There are quite a few products that address this: Persistence, CocoBase, TopLink, Novera, Aptivity, Objectmatter, Softwaretree, Watershed, ProEnable ... I'm sure this list is out of date.

Most or all of these automatic mappings are fine, but don't generate efficient queries that across several tables. And they can't: the need for this completely application dependent. Special dedicated objects accessing database views are sometimes a solution to this.

> every additional "fashion" or
> flavour of thinking complicates our business.

I would also argue that using the right tools for the job makes our business less complicated (e.g., don't use a hammer for screws, kind of thing).

                                                                      Philip

-- 
If you have a procedure with 10 parameters, you probably missed some. (Kraulis)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijnzaad_at_ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639                 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           \ Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53