Re: Newbie question on table design.

On Apr 29, 9:00 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> "-CELKO-" <jcelko..._at_earthlink.net> wrote in message
>
> news:1177850477.793972.30990_at_y5g2000hsa.googlegroups.com...
[snip]

> > >> "row" and "record" is more a matter of terminology than concept. <<
>
> > I disagree. Rows are not records. A record is defined in the
> > application program which reads it; a row is defined in the database
> > schema and not by a program at all. The name of the field is in the
> > READ or INPUT statements of the application; a row is named in the
> > database schema. Likewise, the PHYSICAL order of the field names in
> > the READ statement is vital (READ a,b,c is not the same as READ c, a,
> > b; but SELECT a,b,c is the same data as SELECT c, a, b.
>
> Again, this is simply not true. In the later days of COBOL and file based
> applications, record definitions were stored in libraries, and referenced
> by COBOL source programs. These record definition libraries eventually grew
> into active data dictionaries.
>
> You are vastly oversimplifying the historical evolution of data management.

Simplified, yes. Overly simplified is just your opinion.

There is a significant difference between accessing file records and accessing rows. How terminology is used expresses deeper meanings and understandings. It is like St Paul's advice that the strong should still follow strict rules so as not to mislead those weak in faith.

Here's a final argument: if there really was no difference and the transition from records to rows was as gradual as your seem to be arguing here, then why did the term rows come into use? There was a reason. There is a difference at a very fundamental level.

  Ed Received on Wed May 02 2007 - 04:45:35 CEST