Re: Advice on SQL and records

"Paul" <paul_at_test.com> wrote in message news:4309d82b$0$97095$ed2619ec_at_ptn-nntp-reader03.plus.net...
> David Cressey wrote:
> > Ooops! I didn't get it until I read the question again. Ignore my
earlier
> > response The correct answer is that none of the SQL tables contain any
> > records. SQL tables contain rows rather than records.
>
> I don't really understand this obsession with calling them rows rather
> than records. A row records a fact, so does it really matter it we call
> it a record? I realise that it is maybe to distinguish between
> COBOL-style row-by-row processing as opposed to set-based processing,
> but I don't really see it as that important. You can still call them
> both records but appreciate the difference.
>

Funny you should say that. When I first started with a relational DBMS, VAX Rdb/VMS, they didn't use SQL as the interface, and they didn't use SQL terminology. What later became known as "tables, rows, columns, and domains" were called "relations, records, fields, and global fields." It never bothered me at all to call them "records".

What I think irritates Joe Celko is that people who carry over the terminology of "records and fields" tend to carry over the thought patterns of single record at a time processing. Those thought patterns lend themselves to bad database design, and bad query design. I agree with Joe, up to a point. But I have to give you the point as well. I never had a problem thinking in terms of sets of records, once I had mastered Datatrieve, which I did before going on to Rdb.

> You could argue that "record" is a better term because "row" has
> implications of physical rather than logical structure.
>
I disagree.

> I might start calling SQL rows "records" all the time now, just to annoy
> the language purists! :)

Hee, hee. I love it, regardless of whether I agree or not. The language police should always be given a hard time, else we will all end up with newspeak. Received on Tue Aug 23 2005 - 02:21:44 CEST