Xref: utzoo comp.sys.mac:19989 comp.databases:1348 comp.sys.mac.programmer:2306
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!amcad!stech!sysop
From: sysop@stech.UUCP (Jan Harrington)
Newsgroups: comp.sys.mac,comp.databases,comp.sys.mac.programmer
Subject: Re: Databases: distributed vs. monolithic file structure (was Re: FoxBase)
Message-ID: <652@stech.UUCP>
Date: 3 Sep 88 09:13:07 GMT
References: <6178@dasys1.UUCP>
Organization: Scholastech, Inc., Waltham, Mass.
Lines: 53

in article <6178@dasys1.UUCP>, alexis@dasys1.UUCP (Alexis Rosen) says:
> 
> 
> There has been some discussion recently in comp.sys.mac concerning the relative 
> merits of two different methods of storing database files: the monolithic 
> (all-in-one-file) way and the distributed (files-all-over-the-place) method. 
> Since this issue is very important (to those of us who use databases), and 
> apparently not too well understood, I will try to explain why the distributed 
> method is far superior to the monolithic method.
> 
> The benefits of monolithic structure are few. First, you don't have to look at 
> all those files filling up your disk. This is especially important to some 
> consultants who want to present a neat appearance to their clients (no joke- 
> I've seen people choose not to buy a product for this reason alone). Also, 
> there is less chance of losing one file and not noticing it. I do not know of 
> any other reasons for using the monolithic structure. Both of the reasons 
> listed above are purely aesthetic. As far as I'm concerned, just put everything 
> in one folder (subdirectory) and there's no more problem.
> 
> Some of the monolithic-structure databases are:
> Mac- Omnis 3+, Helix, Fourth Dimension (4D)

Sorry, but the only single-file Mac DBMS is Double Helix II. The others leave
all sorts of files cluttering up your folder.

> PC- R:Base
> 
No way - R:base uses THREE files for every database. And heaven help you if
you rename any or lose one!

> The benefits to a distributed structure are far more concrete and important. 
> First of all, in today's imperfect (i.e., non-fault-tolerant) world, keeping 
> all your data files (relations, tables) and indexes in separate files isolates 
There is, however, a major problem with multi-file storage. You dare not
change a file name, index name, etc., etc., without goofing up all your 
application code. In other words, what you do logically with table names,
etc., is dependent on what things are named physically. If the two don't
match, then you've got a problem. (Try renaming a dBase file - any kind of
dBase file - from the desktop. Can dBase (any vesion) figure out that the
file has been renamed and dynamically fix all your application code? No
way. You'll get a "file not found" error!)

Jan Harrington, sysop
Scholastech Telecommunications
UUCP: husc6!amcad!stech!sysop or allegra!stech!sysop
BITNET: JHARRY@BENTLEY

********************************************************************************
	Miscellaneous profundity:

		"No matter where you go, there you are."
				Buckaroo Banzai
********************************************************************************