TMG-L Archives

Archiver > TMG > 2003-05 > 1053889288


From: Richard Brogger <>
Subject: Re: [TMG] Data Sets and Projects
Date: Sun, 25 May 2003 14:01:28 -0500
References: <18c.1ad6e259.2c02252e@aol.com>


wrote:
>
> To separate or not to separate: that is the question. I would submit that
> only you can answer that question.
<snip>
> It all goes back to do whatever floats your boat and makes life easier for
> you. I might add that I have not found the consequences of going either way to
> be earth shaking so your decision probably won't change your life style overly
> much-Dale

There is another group. Those with huge databases that need the
supposed benefits of having one database. Their database can't be
split without losing links and it can't be run in TMG5 on an average
computer.

I have name data sets where only small groups are linked, many records
do not tie to another record. I have family data sets where everyone
in the data set is linked to another person or persons. It does not
matter whether I am working in a name data set or a family data set, I
can only view a small portion of the data at one time. Most often, I
see one nuclear family. While I am viewing that person or family, the
data could just as well be on a sheet of paper. One of the beauties of
a computer is when I want to jump to the father, mother, child or
sibling. A double click and I am in that person's record.

The data for a person is not stored like a sheet of paper that looks
like a Person View. All the data from many tables is brought together
in the Person View or any other view. Each view requires different
different data but it is all linked together in the tables. Whether we
change views or persons we are using a link to call new information
from about 77 different files.

It is links that allow TMG to work the way it does. The user does not
establish those links. Doing so would drive most users to drink. Those
links are established by the program and we never see most of them.
When we add a new person, in effect, we tell the program how we want
that person linked to other persons by selecting a relationship but
that is just the tip of the iceberg. Most of the links that follow are
out of sight of the user and require no user action.

Since on data set is stored in many pieces and we can only view a
small portion of the data at anyone time, what makes one data set
beneficial? It is the links. Split a data set and those links are
broken. If those links did not break, a data set could be any size. If
the data set is small enough, several data sets could reside in memory
at one time and one or more could be replaced in the blink of an eye.
Clicking on a link might open a record in the same data set or in a
different data set. Unless the user watches the Title bar as they
click, they would never know that they had jumped to a different data
set.

A few years ago, I built a 'book' using Adobe Acrobat. The main page
was a box chart for a nuclear family. The box for each person was
divided into four invisible buttons. Clicking on a button would jump
the user to another page. Depending on the button used, that page
might be were the person is the parent if the button was for a child.
If the button was for a parent, the page would be where that person is
shown as a child. Another button for each person would take the user
to the text for that person. Another button would take the user to
that person's first exhibit. Buttons on each exhibit would jump the
person either to their main page or to the next exhibit.

Once I had built a demo, I was going to send it to a relative to
preview and make comments. It was too large to email. Images
especially were a problem. I split the file into several pieces and
re-established the links that splitting broke. I could then send the
book as several e-mail attachments. Once the recipient placed the
individual file into one folder, the files worked together as one
book. Clicking a link might, in effect, turn the page or it might jump
the user to another file. The only way to tell what happened was to
watch the file name. If it changed, you knew it was a different file.
There was no pause while a new file opened. The file called by a link
could be in the same folder or another folder. The link could have
been to another drive. Adobe Acrobat did not care as long as the path
was valid. My point being that there was no magical boundary around
the files in a folder. Any 'page' could be linked to any other page,
regardless of how many boundaries were crossed.

> So I separate them because I want
> to work with as small a data base as is practicible. The pick list is easier
> to navigate, the source list is shorter etc. Backup is shorter since sometimes
> I will not work on the Kentucky family for maonths at a time while I work on
> thew Illinois bunch. The Kentucky bunch gets backed up to a CD or Zip disc and
> stays at an off site location until I need it again.

Imagine if you will how nice it would be to click on the another son
of that ancestor and your are asked to put your Kentucky disk in the
drive. Once you did so, you would go to the right person in the
Kentucky line. Imagine also that TMG had a Picklist option to show all
persons in selected data sets or all data sets. TMG would store the
names and links on your hard drive and keep that file current as
people are added to any data set. Click on any name and you jump to
that person regardless of where their data is stored. If the data set
is on the hard drive, the jump would be instantaneous. If it on a
floppy, CD or Zip drive, there would be a delay while you inserted the
media.

If you want to move data sets, say from Zip to CD, that move would
have to be done from within TMG so that TMG could refresh the links.
If you forget and move the files from outside of TMG, the links would
be broken. The first time a link was used, the user would have to tell
TMG what the new path was so that it could change all of the links.

> I choose to separate those two sons and their
> families into two different data bases. The only connection between the two families
> I have ever found is back at the beginning.

For a human to split data sets, it is best that there not be many
connections. Software does not need to be so limited.

> On the other hand I have
> families that are entertwined at different generations and separation would
> lead to all sorts of problems.

What problems? TMG is able to link those entertwined relationships no
matter how complex they are. Just don't break the links. <g> Other
programs can and do allow separation but they also maintain the links.
IMatch is a good example. If I use IMatch to move image files, IMatch
does not care where I move them and that includes off-computer
storage. Double click on a thumbnail and the image file will open if
it is available. If it is not available, I am told what media to
install. It takes a database just to keep track of where everything is
so that links are current but that is what computers do well. Can you
imagine opening an IMatch database if that meant loading all the image
files that are tracked by IMatch. I would have to plan ahead and open
IMatch just before I went to bed so I could use it the next day. Thank
goodness that it only loads the image files as I need them.

> It all goes back to do whatever floats your boat and makes life easier for
> you. I might add that I have not found the consequences of going either way to
> be earth shaking so your decision probably won't change your life style overly
> much-Dale

For that average user, splitting or not splitting will not change
things overly much. However, there are those for whom splitting
without loosing links would make TMG5 really usable. Even smaller data
sets could be split and the user would gain. When you make changes in
your Illinois data set, that is all you need to back up. If they were
combined in one data set, every backup would contain those records for
the Kentucky folks that have not changed in months or years. If the
combined data set has 50,000 people, how many of them are in every
backup but the record has not changed? If a user starts a backup and
then heads for the kitchen to get coffee, that backup is too darn
large. Worse yet is when they go mow the lawn while the backup is
being made. IMO, the time it takes to make a backup should be under
ten seconds. Anything more and the data set needs to be split, if the
links were not lost in the process.

Richard Brogger

This thread: