Historical research database
- On 28 Nov 2009 at 21:50, ray_murphy aus wrote:
> --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@...> wrote:I have got SOME sort of program started, which I use tio collect data.
> > 1. The need for an event-based database program for genealogists,
> > historians, biographers etc.
> I'm trying to help out here by continuing the discussion - hoping that it will
> make your idea clearer for the rest of us.
> I spent several months (as an amateur programmer) making two different
> programs - one in MS Access and the other in Visual Basic, but they were
> nowhere near as complex as your idea sounds, even though both programs store
> literally any type of event, relationship (family, business, social etc), plus
> any characteristic or quality that one could ever imagine for any given person
> or entity, including animals.
> The reason those two programs are not complex like your idea sounds, is
> because they are not relational databases. The event data etc is simply
> selected from the program's listboxes and the dates are entered with the
> keyboard and both go onto the entity's file card.
> If the programs don't have suitable selections, then a user can just create
> new categories on the fly and they become part of the program - so those new
> categories don't have to be typed in repeatedly.
> I'd suggest after going this far with my own programs, that unless there is a
> 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'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 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.
> From what I can gather from your comments about harvesting all sorts of data,If by "orphan" material you are referring to the need to type in the same
> it sounds like there could be a huge amount of 'orphan' material involved.
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.
Phone: 083-342-3563 or 012-333-6727
- --- 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.