[postgis-users] Re: Database design book recommendations for the person who asked

[Chris Hermansen]

I think one of the main problems with SQL is that the concept of tuple
should be more "up front".

What do I mean by that?  Well, a table is a tuple of tuples, surely you
could have a tuple of tuple of tuples, and you should be able to slice
any of those (SELECT is a kind of slicing operation with a lot of
features removed).

SQL SELECT is kind of dumb that way.

In general, I think that the above kinds of problem comes from an
attitude that informed the original "design" (if you can call it that)
of SQL - "users are far too stupid to ever understand this relational
model thing properly, we have to dumb it down for them".

The SQL UPDATE statement is so frustrating, WHY !@)(*#&!@(#*$&#!@* does
it not permit a table join!!!  And don't give me that correlated
subquery nonsense.

Maybe you could blame this on implementations, but I have to say that
any time I'm faced with doing a correlated subquery in any database
system I've ever used, I fear it's going to be way slower than stooging
around with temporary tables, and I don't think I've ever been wrong
about that.  Mind you I've only been using SQL since 1984.

Again, maybe this is an implementation issue, but extensions are hard to
do.  For instance, the whole PostGIS thing and that geometry_columns and
spatial_ref_sys tables really ought to be system tables, and wouldn't it
be nice when you CREATed a table containing geometry if there was
something that would note this automagically and put corresponding info
in the (system) geometry_columns table.  Not to mention a DROP TABLE
statement that could be customized to unhook the geometry info...

Why is there not a standard for stored procedures to which database
software designers adhere?  Same question for triggers.

There are also some problems that are really hard to do in SQL; usually
when I only need to solve them once in awhile, I suck the data out into
awk or Python and do it in relational memory.

I'll stop here.

Webb Sprague wrote:
>> Date compares SQL to Cobol.  I
>> disklike SQL a lot, but that seems a bit extreme to me, maybe it's the
>> FORTRAN?
>>     
>
> I actually don't understand why people dislike SQL, though I can
> understand that there are theoretical problems with it....  I know I
> am supposed to dislike it too, so I am a bit bashful here...
>
> -W
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>   


-- 
Regards,

Chris Hermansen · mailto:clh at timberline.ca
tel:+1.604.714.2878 · fax:+1.604.733.0631
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5

C'est ma façon de parler.