--- In email@example.com
, "Steve Hayes" <hayesstw@...> wrote:
> On 29 Nov 2009 at 7:15, ray_murphy aus wrote:
> > --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@> wrote:
> > > The disadvantage is that the PEOPLE field is a repeating field. There can be
> > > many people associated with a single event, and there can be many events
> > > associated with one person.
> > RM: Virtual file cards are needed so that names are not duplicated - so to
> > state the obvious, it needs a master list (or index) of Names which can be
> > clicked-on to bring up each file card. That's easy to do in Visual Basic or MS
> > Access or most other programs from what I can gather.
> I'm not sure what you mean by a "virtual file card".
RM: Don't worry, it's not another new term to learn. I was just referring to a visible filecard.
> How does that differ from a table, and what are the advantages of using one?
RM: Before I go any further here, I'm no expert with any of this stuff - far from it, but the software I've made for my own non-genie projects has all worked ok, so I thought I might be able to help - especially while there is not much other input.
Advantages of 'file cards' over tables:
According to one of the Microsoft experts we shouldn't even be using
tables for data entry. Apparently they are mostly used for background
storage of the data - and it is forms (containing the same information) that should be used instead - and non-programmer users of a database should never be allowed anywhere ~near~ tables.
Of course sometimes a small table is built in to a form - especially for the 'file cards' I was referring to. If we were not using them we might be using listboxes in their place.
> > Once those virtual file cards are in place, all events (and their dates) could
> > be added to each involved-person's file card with a few mouse clicks. For
> > example for a category like "Present at Marriage Event - St Marks church 14
> > Nov 1883" could be typed in as a new Event, then you just whizz down the index
> > from A - Z and click on the name of each person who attended (which brings up
> > their file card) and then click on that Event to add it or anything else like
> > source.
> > A relational database couldn't do it any faster because it would still need to
> > receive the same input from the person entering the data. It would be a
> > different if a relational database was going to figure out and record highly
> > irrelevant things like "Cousin attended marriage at St Marks" - which would be
> > a strange genealogical type of connection to an event.
> As far as I am aware MS Access IS a relational database program that allows
> you to create and link tables. I've posted a model of the kind of tables and
> links I envisage in the "Files" section of this forum's web page.
RM: Yes, MS Access does a great job with all of that - and that is what is needed to have automatic and accurate updating of family relationship information that is scattered all over the database, however I'm still not seeing a need for such sophistication for events (and similar types of things like illnesses or causes of death etc).
If lots of events were to be included in an existing genealogy program, it might be necessary or valuable to have some new relationships automatically handled for us, but as things stand, most people are not even interested in talking about events - let alone suggesting good ways to handle them or express personal preferences for dealing with event add-ons.
As you can see, I'm actually interested in the recording of events but I still cannot visualise many situations where event information could be used for genealogy or how it can be handled easily by the average user - so it looks like we need some examples to motivate us.
> > >That is what makes a relational database a better solution. One can >then
> > >type in a person once and an event once, and put the person's >relationship
> > >to the event in a link field.
> > >
> > >One can then create reports for the events in a person's life, or >the people
> > >associated with a particular event.
> > RM: But that's easy to do without using a relational database - by either: (a)
> > printing a person's file card - showing all their events etc, or (b) printing
> > the Event and seeing the names of all those who were there.
> Again, I'm not sure what is the difference between a table and a "file card",
> and what the advantage is of using the latter rather than the former.
> > Also - if St Marks was a "busy church" for a particular family, there could be
> > a whole string of events listed for it - and everyone in the database who ever
> > had anything to do with St Marks could easily be listed in a final printout
> > in: * Name order * Event type (christening, marriage, or current pastor,
> > minister etc) * Date order
> > I suppose a lot depends on what the printouts or on-screen summaries would be
> > used for - and what sort of information is desirable to have. For example in
> > the above case, where a particular church was prominent for many years, a
> > summary of all known events connected with it may well show which minister
> > probably signed a register if the signature was hard to read.
> In my schema, St Mark's Church could be entered as an "organisation" in the
> "Organisations" table, and events listed as linked to it could be used to
> compile a parish history, if that was what was wanted.
RM: That can be done easily with ordinary software code and without the complex linking of anything in MS Access. It's just a matter of clicking on St Marks (at x location) and clicking on names and clicking on events and typing (or selecting) the dates. A relational database could of course do ~some~ of it without human input but only where people spelled the name and location exactly the same in the typed or harvested text, so it's easier and quicker to just click on items.