Xref: utzoo comp.sys.mac:20107 comp.sys.mac.programmer:2381
Path: utzoo!attcan!uunet!dasys1!alexis
From: alexis@dasys1.UUCP (Alexis Rosen)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: Databases: distributed vs. monolithic file structure (was Re: FoxBase)
Message-ID: <6319@dasys1.UUCP>
Date: 8 Sep 88 11:29:39 GMT
References: <6178@dasys1.UUCP> <652@stech.UUCP>
Reply-To: alexis@dasys1.UUCP (Alexis Rosen)
Lines: 64


in article <652@stech.UUCP>, Jan Harrington (sysop@stech.UUCP) writes:
>in article <6178@dasys1.UUCP>, alexis@dasys1.UUCP (Alexis Rosen) says:
>> [lots of stuff about why mono structure DBMSs are bad on the Mac]
>> 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.

In fact, Omnis uses exactly two files. 4D uses one file for all your data, one
for each index, one for your programs, and a couple more more other stuff (but
the new 4D V2.0 will use just one file for everything, I hear). But you're sort
of missing the point. I was trying to avoid some unnecessary detail. _All
three_ of these programs share the major characteristics I was criticizing in
my article- inability to distribute data files and double file access overhead. 

>> 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 same thing applies here. Rbase has one file for all data, one file for all
indices, and one file for internal information. All the problems I attributed
to a mono structure exist for Rbase as well. (In addition, rbase is a terrible
product, but that's a different article, and a different newsgroup...)

>> [more on benefits of distributed file structure]
>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

This can be considered a drawback, but it's hardly a 'major problem'. What are
your users doing messing with your files? For that matter, why are you careless
enough to leave them unlocked?

If it's experienced users you're dealing with, normal ones will NEVER have this
problem because they simply don't use the folder (or subdir) containing the
database files. If they're malicious, you've got a general security problem,
and they could delete your entire mono-structured database just as easily as
they could wipe out one index in mine...

Anyway, if you can write decent code, you can arrange things so that you only
have to change the assignment of physical files to logical descriptors once in
your code. One of the things I often do for larger projects is write a little
utility that puts files where I want them and then changes my code (in ONE
place) so the database still works perfectly. It's very easy to do.

----
Alexis Rosen                       {allegra,philabs,cmcl2}!phri\
Writing from                                {harpo,cmcl2}!cucard!dasys1!alexis
The Big Electric Cat                  {portal,well,sun}!hoptoad/
Public UNIX                         if mail fails: ...cmcl2!cucard!cunixc!abr1
Best path: uunet!dasys1!alexis