Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.databases
Subject: Re: Databases: separate-file vs. monolithic file structure
Message-ID: <3214@geac.UUCP>
Date: 11 Sep 88 16:17:40 GMT
Article-I.D.: geac.3214
References: <976@sybase.sybase.com>
Organization: GEAC Computers, Toronto, CANADA
Lines: 58


In article <6299@dasys1.UUCP> alexis@dasys1.UUCP (Alexis Rosen) writes:
| Recently, Tim Wood wrote a response to my article on database file structures
| ... I guess I was very unclear here. 
| What I was saying was that in many cases, with canned applications, you have 
| knowledge that certain tables will never be written to except by one user 
| (exceept on weekends, on Feb. 29, and during a Solar eclipse. Whatever...)
| In this case, you need not establish a lock and can just do whateer you like 
| without worries. This is what I meant by it being 'not a problem'.

From article <976@sybase.sybase.com>, by tim@linus.sybase.com (Tim Wood):
|  The only problem is trivial applications.  Inability to support general
|  concurrency with consistency severely limits the ability of your system to
|  model the real-world problems you are trying to solve.   

  Actually, one wants to use a system with locks even in the trivial
case: what you're avoiding is the cost of dealing with collisions 
as opposed to the cost of locking.
  In a good system, the cost of establishing a lock can be small.
For example, on Unix, one can write ones' lock-manager critical code
as a dummy "device" driver[1], and ensure the software path for a
successful lock is relatively short, on the order of magnitude of a
single system call.
  This is not necessarily true of a collision-resolution system:
there is a fair bit more work involved here, often (but not always)
on the order of a process switch.
  (Yes, there are PC/Mac databases in which locking is frighteningly
expensive... but they don't **have** to be that way: see also [1])

  In a large library system my employer was (re)building on top of
Ingres, we noted that the nature of the real-world construct being
modeled precluded almost all possible collisions (No two people can
borrow the same copy of a book at the same time, unless they tear it
in half).
  This allowed us to run prototypes with no locking (because they
had no real database!) and still get self-consistent results.  When
we did the next prototype, though, we used the database with locking
turned on and saw a moderate speed improvement (The DBMS was smarter
than the proto-kludge).  We kept the locking, arguing that we could
not preclude administrative-correction transactions which would
require locking to function (ie, we found out the patron was using
someone else's card, or that the book was mis-labeled, and a
librarian was unmunging the now-incorrect model).

  The system ran "far faster"[2] than one which had collisions on the
patron tuple when it tried to parallelize charge-out transactions...

--dave (once upon a time a boring programmer-type who
        worked with extra-boring librarian types) c-b

[1] This can be done on Macs and probably OSdiv2: see the last issue
    of MacTutor for an example. You can also cheat and make it always
    return YES in the single-machine single-user case.
[2] Purely estimation, alas.
-- 
 David Collier-Brown.  | yunexus!lethe!dave
 78 Hillcrest Ave,.    | He's so smart he's dumb.
 Willowdale, Ontario.  |        --Joyce C-B