Re: Questions about multiuser locking in database design

From: Jerry Gitomer <jgitomer_at_erols.com>
Date: Thu, 31 Jan 2002 22:34:37 -0500
Message-ID: <3C5A0CCD.5B96D8F8_at_erols.com>


Walt wrote:
>
> On Thu, 31 Jan 2002 00:11:42 -0500, Jerry Gitomer <jgitomer_at_erols.com> wrote:
>
> >Locks should be at a record level except when physically
> >reorganizing indexes.
> >If I remember correctly you are using flat files and therefore,
> >by definition,
> >won't have any indexes to reorganize, so in your case, use
> >record level locks.
>
> Uh-oh, you've unearthed either a terminology error on my part, or a big hole in
> my understanding.
>
> By flat files, I meant that it wasn't relational - tables of records stand
> alone and won't need reorganizing based upon other tables that change. But I
> have written index files, ordered sets of record numbers again various indexed
> fields so the database can be searched quickly by more than one field. What did
> I miss here?
>

Terminology. Flat files are sequential files without indexes. If all
of the records in a flat file are the same size you can update in place,
if not you don't dare take a chance on messing up the file. All new
records are added at the end of the file and deletions occur by flagging
deleted records which are then dropped the next time the file is copied.

Databases, be they relational, hierarchical, network, or object oriented
have indexes. (In theory they may not require indexes, but in practice
they do in order to realize satisfactory performance.)

Then there are things like IBM's old time ISAM and VSAM which are indexed
file systems, but are not DBMS. If you are doing your own indexed file
system check out the specs on VSAM (Virtual Storage Access Method). If
you are building commercial systems you won't find a better model. IBM's
goals were to build a bullet proof system that their biggest customers
could rely on to protect the integrity of the data come hell or high water.

take advantage of their experience. Received on Fri Feb 01 2002 - 04:34:37 CET

Original text of this message