Re: Unknown SQL

From: Joe Cosby <joecosby_at_SPAMBLOCKmindspring.com>
Date: Sun, 22 Jul 2001 18:27:02 GMT
Message-ID: <3b5b172a.8911847_at_news.mindspring.com>


"Carl Rosenberger" <carl_at_db4o.com> hunched over a computer, typing feverishly;
thunder crashed, "Carl Rosenberger" <carl_at_db4o.com> laughed madly, then wrote:

>A database without set logic (some present object databases) does not
>require you to think in sets. You only think in terms of single objects.
>
>Agreed, a declarative query interface to create sets is a feature that is
>needed in most database applications.
>

Well how exactly do you define a set of data if not as a set?

>> It's got a fairly small vocabulary.
>
>Yes, but there are lots of things to learn, which are not part of the ANSI
>vocabulary. It takes a lot of experience to know most of them and to take
>the right decisions.
>Some themes:
>- how do I retrieve newly inserted keys?
>- which vendors support what?
>- how do outer joins work?
>- where is the "handle" to the result? (there is none!)
>- how do I constrain columns of an outer join?
>- which date format do I use?
>- do I use meaningful keys?
>- why do I need a group-by on every column to work with sums?
>

But for the most part, these don't come under the category of 'learning SQL', or have anything to do inherently with SQL as a query language. You're talking about behavior of the database system itself, and learning what the vendor supports and how.

And for the most part, these would all be easier if the vendors A. Supported SQL uniformly
B. Supported SQL more thoroughly

>- how do outer joins work?

Agreed, that is a complicated part of learning SQL, but if you want that functionality, you're going to have to learn something analogous.

I mean we've got
- retrieve a set of data
- retrieve a set of data based on a relationship between two data sets (join)
- but wait! I want to retrieve all matching records from set A whether there is a corresponding record in B or not

However you implement it, the need for that kind of retrieval is going to be there, so you're going to need something analogous to an outer join. And the user is going to have to learn whatever it is you implement.

I guess my point is, it's inherent to the nature of a complex data retrieval request. A lot of SQL can be a little mind-boggling like that, but if you have a need for something like that kind of data retrieval operation (i.e., an outer join) then you're going to have to learn some way or other to indicate it to the database.

>- which date format do I use?

Here I agree, I think SQL's handling of datatypes in general is outdated.

--
Joe Cosby
http://joecosby.home.mindspring.com
 
Philosophy is a battle against the bewitchment of our intelligence 
by means of language. 
- Ludwig Wittgenstein 

 
 
Sig by Kookie Jar 5.98d http://go.to/generalfrenetics/
Received on Sun Jul 22 2001 - 20:27:02 CEST

Original text of this message