Re: Historical research database
- --- In email@example.com, "Steve Hayes" <hayesstw@...> wrote:
> On 28 Nov 2009 at 21:50, ray_murphy aus wrote:
> > --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@> wrote:
> > I'd suggest after going this far with my own programs, that unless there is aRM: 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.
> > clear demand for a certain type of data to be gathered, then just get SOME
> > sort of program started, and see what is needed as real data is gradually
> > entered. That's all I did - and I kept seeing new opportunities, problems and
> > needs as I went along.
> I have got SOME sort of program started, which I use to collect data.
> I've actually got several started, not as relational databases.
> One is a family event database, which I have entered in a flat-file text
> This is the data structure (field list)
> Name of structure: EVENTS
> Description line (optional): New Events structure
> Record ID field(s): ID
> Order key field(s): EVDATE
> Type LABEL NAME INDEX SORT EMPHASIS for each field
> F/1 ID * T 2 1
> F/2 ED EVDATE T 4 1
> F/3 EP EVPLACE Y 9 1
> F/4 EV EVENT Y 9 1
> F/5 EN EVNOTE K 9 1
> F/6 PE PEOPLE Y 9 1
> F/7 SO SOURCE Y 9 1
> F/8 DN DOCNUM Y 2 1
> F/9 NO NOTES K 9 1
> F/10 CO COMMENTS N
> F/11 KE KEYWORDS K 9 1
> F/12 UD UPDATE T 4 2
> Stop words: A AN AND BY FOR FROM IN OF ON THE TO WITH
> 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.
That's easy to do in Visual Basic or MS Access or most other programs
from what I can gather.
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.
>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.RM: But that's easy to do without using a relational database - by either:
>One can then create reports for the events in a person's life, or >the people associated with a particular event.
(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.
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.
> > From what I can gather from your comments about harvesting all sorts of data,I was thinking about the wholesale inclusion of any and every event that semi-automated internet harvesting could yield. Sure, it would help to join a few dots that would otherwise be missed, but there could be umpteen thousands of events that were connected to only one person - and they would start clogging up the Event index.
> > it sounds like there could be a huge amount of 'orphan' material involved.
> If by "orphan" material you are referring to the need to type in the same
> person's name in relation to numerous events in a "flat-file" database, yes,
> that is true, and that's why a relational database might be better.
- --- In email@example.com, "ray_murphy aus" <raymurph@...> wrote:
> --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@> wrote:
> > On 3 Dec 2009 at 19:11, ray_murphy aus wrote:
> > > --- In email@example.com, "Steve Hayes" <hayesstw@> wrote:
> RM: I've already got that test VB program working and displaying all the required events, sources and people, but as it turned out, it didn't need MS Access or its complex linkage system at all.[....]
> The user-interface being used would be the same under any system,
> and irrespective of what was happening in the background with tables,
> linkages or arrays.
A much better version of the VB program has been uploaded to the Files section of this group's website. It's called "GENEVENTS2"
It can be used to store literally anything that one could ever imagine because users can add their own categories for Events, Facts or Relationships between people.
Any date system can be used, but if full automatic sorting is required for print-outs, then we need to use the YYYY,MM,DD format. If however some dates are not in the correct format (and order in a printout) then they can be simply re-positioned by Copy/Paste in the print-out panel.
If "Connected People" are required for event descriptions, then just click on their names and they will be automatically inserted.
If Sources of information are required for events etc, then they simply need to be entered with the event.
The program has a concise Help section in the Menu, so most questions will be answered there.
This latest version should make it easy for anyone to create a database with a SUITABLE 5.5 Gedcom and start seeing future potential or current weaknesses with the system.