on 10/9/00 10:22 PM, Colin Cooler at [EMAIL PROTECTED] wrote:
> Am I "over-designing" this solution or correctly addressing the issue? Are
> there any "referential integrity" issues with FMP I will need to consider?
> Should I rethink and try and consolidate more of this within ebase?
>
> Once again at the Well and praying to the Great Indexer,
> Colin Cooler
Offhand, what you suggest in terms of file structure looks right. I have a
couple of comments:
Since the students, officers, and volunteers are not likely to be making
donations, you're basically using eBase for contact management and the
"Activist" screen, right? Will you be doing mailings to these people? Do
you envision using some of the other built in functions?
I ask because if I were in your shoes, it'd seem easier to me to build the
files from scratch than to customize ebase. You're going to be building
some pretty sophisticated relational stuff, reporting, etc, and in terms of
mental/emotional overhead it might be easier than trying to fit 40% more
functionality into what's essentially 10% of screen real estate.
"Referential Integrity":
Since you have 3 different kinds of contacts, you're going to have to handle
them in one of two ways, for relational and reporting purposes: build a new
Key Field (a calculated concatenation of Record Type (S for student, V for
volunteer, O for officer) and Record Number - i.e V-12321, S-11321, etc) or
have a datafile for each kind of contact. Which way you go depends on how
much reporting, mailing etc you would have to replicate and maintain if they
were in separate files.
The problem with the former method is that it would force you to maintain
two Key Fields in eBase - one for existing relationships, one for
relationships to new files.
The problem with the latter is that you'll have to add two extra contact
files to eBase, and maintain label layouts, payment stuff, etc. So maybe
the former method is better.
Why is the former useful if you keep all contacts in the same file?
Envision an activities line item database which is basically a list of
attendees. You've got the Contact ID (Record Number(either new or old) from
eBase), the Event ID (from the Parent file, the Activities database), and
whatever else you want in there; fine. That's no problem, you could build a
report that sorts by Record Type, and show Officers, Volunteers, Students
etc.
But when, say, I want to see which Students an Officer has worked with *over
the life of his/her involvement*, how do I differentiate between Students
and other Officers or Volunteers? I can't, exactly - not by virtue of the
Record Number - I have to perform a find or a sort. And for user's purposes
I can do so only through scripted reports which find on Record Type. THE
RELATIONSHIP ITSELF DOESN'T KNOW which is which. So you can't, say, view
those students in a portal.
Hope this helps- it's kinda random.
Colin
