Re: Newbie question on table design.

From: David Cressey <cressey73_at_verizon.net>
Date: Sun, 29 Apr 2007 13:00:37 GMT
Message-ID: <VF0Zh.4121$r77.547_at_trndny08>


"-CELKO-" <jcelko212_at_earthlink.net> wrote in message news:1177850477.793972.30990_at_y5g2000hsa.googlegroups.com...
> >> There are numerous record management systems that allow for concurrent
access by multiple processes. <<
>
> The record systems I know used a job queue and locks. They could not
> even share read-only data very well. We had all kinds of schemes for
> handling the queues, but the model was that you had to wait until the
> other user was done with his changes. The early SQL systems were also
> built on a queues and locking model because that is what we had.

Synchronizing processes (locks) is one way to allow for concurrent access without allowing race conditions. Saying that a system uses locks is NOT the same thing as saying that it doesn't provide for concurrent access.

>
> There was no concept of optimistic concurrency control or parallelism
> via logical partitioning when changing the data.

The above is NOT inherent in the definition of "row" and "record".

>
> >> "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.

> All empty files look alike; they are a directory entry in the
> operating system with a name and a length of zero bytes of storage.

That's only one way of looking at empty files. Received on Sun Apr 29 2007 - 15:00:37 CEST

Original text of this message