Re: cdt glossary - TABLE

"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1121047421.545287.227300_at_o13g2000cwo.googlegroups.com...

> Part of the problem here is that people are not used to thinking
> about interface separately from implementation. Thus as soon as
> they are presented with an abstraction, they immedately conceptualize
> it in terms of the first implementation they can imagine. (Not saying
> you are doing this, Jan-- it's just something I've observed in a lot
> of people, and I think it really contributes the difficulty people
> have with thinking about unordered information.)

Spot on!

I think I was doing this with regard to "tables", although I should know better, by now.

SQL is a confusing interface in this regard, because it provides the DDL interface (CREATE, ALTER, DROP)
as part of the same interface as the DML (SELECT, INSERT, UPDATE, DELETE). On a practical level,
this is pretty handy, and I'm not sorry the SQL people did it this way.

However, the merging of DDL and DML makes it easy for SQL jockeys to blur the distinction between a table as an interface construct and whatever implementation of tables the DBMS has, behind the scenes.

Speaking of "unordered information", somewhere deep in my brain, I still think of "memory addresses" as imposing order on stored data, regardless of whether the data is inherently ordered or not. That's how I learned it, long, long ago. Received on Tue Jul 12 2005 - 01:26:46 CEST