At 12:01 AM 5/26/01 -0500, you wrote:
>Subject: Additional Tables
>From: Tom Childers <[EMAIL PROTECTED]>
>Date: Fri, 25 May 2001 16:12:59 -0400
>X-Message-Number: 11
>
>Hi All,
>
>We're using ebase 1.0 on Filemaker 4.1 and Win 98.
>
>I've got a volunteer who's developing some new tables for us at an off
>site location. He does not have a copy of our ebase; he's just
>developing the tables at his home using a copy of Filemaker 4.1. We hope
>to integrate these new tables into our existing ebase. Any reason why
>this can't be done? I'm assuming that he can just bring his new tables
>here to our office on a floppy, copy them over to the ebase directory
>and from there create the necessary relationships between his new tables
>and our existing ebase.100 tables. Also, we'll link to the new tables by
>creating the necessary buttons and links on the ebase screens. I presume
>he'll need to name the new tables with the .100 prefix. Any other issues
>I need to be aware of when we do the integration?
Please excuse this advice if it covers territory already familiar to you,
or suggests considerations you've already gone over. I find that many
people jump too quickly to the conclusion that new tables are what is
needed to "improve" or "customize" a database...
My primary advice is to think pretty closely about whether you really have
a "new subject" that warrants new tables. In classic data management
thinking, a "table" represents a definition of an "entity" or "thing" about
which you want to maintain information. Every "row" or "record" in the
table represents one "instance" of that sort of "entity" about which you
want to track information. While this degree of formality and rigor seems
like a lot of fuss, my own experience is that there are long-term payoffs
to considering your plans for "improvement" or "customization" pretty
cautiously with regard to these criteria.
Are you really adding information about an "entity" or "thing" for which
there is NOT already an existing table in Ebase? If so, then a new table
makes a lot of sense.
Are you really just adding additional "attributes" of interest for "things"
or "entities" which are already represented by existing Ebase tables? If
so, then a new table might not really be that important.
In my work with organizations who want customizations of Ebase, it usually
turns out that they just want to track additional attributes of "persons"
who they are already maintaining contact records for. For this purpose, I
think adding fields to the CUSTOM table already provided in Ebase is a
pretty desirable approach, as I interpret each "row" of the CUSTOM table to
represent a "person". Other pragmatic advantages are that the additions
can be accomplished relatively quickly, and the changes made have a certain
"simplicity" of concept that results in ease of maintenance - since the
basic mechanisms provided in Ebase don't have to be
altered. Customizations carry commensurate long-term maintenance issues
right in the door with them. More "complex" or fundamental modifications
carry bigger maintenance implications. You should try to rationally assess
these costs BEFORE you make your decision about HOW to make your
customizations.
>Another thing I might do is just give him a copy of our whole database
>on a Zip disk so he can doo all the integration work at his place.
If you can avoid working in your copy of the database for a few days, this
can work VERY nicely. It might be important that all the mechanisms for
making your changes be well researched and prototyped by your database
worker in advance, so that the database is shut down to your access for the
shortest time possible. Then you just replace your copy with the returned
copy when the modifications are implemented. This is the approach I have
used repeatedly, with very good results. I know there are other workable
approaches, but the simplicity of this approach makes it pretty reliable.
>Thanks!
>
>--
>Tom
>Tom R. Childers
>Joy of Sports Foundation
>703-619-0037
>fax-703-619-0038
>http://www.joyofsports.org
>"Helping youth learn life success skills!"
>Mail to: 7906 Andrus Rd., Suite 17, Alexandria, VA 22306
>
>
**************************************************************
Larry F. Bednar
Consulting in Statistics, Quality, Data Managment
Portland, OR 503.493.8542 [EMAIL PROTECTED]
**************************************************************
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
