17 replies to this topic

[Vyger]

Several years ago I took the decision to move towards maintaining one master genealogy database. That decision was brought about mainly by the difficulties of duplication in Places and Sourcing through minor recording differences but there are also the difficulties of differing sentencing, custom reports, repositories et al.

 

My reason for starting this specific discussion is to try and understand how other users have progressed over the last several years:

 

Are you moving more towards one master database?

 

Are you moving more towards smaller specific data sets?

 

How do you manage the Places, Sources, Sentencing etc difference between different RM files?

 

What could Rootsmagic do in your opinion to overcome the challenges of working in a very large database?

 

In my opinion one Master Database is the logical direction to take maintaining all the Core aspects of your work in one single place. I also understand Rootsmagic does not facilitate this very well at present and past development to export and import core database components and the Compare Files feature may suggest a path of helping multiple database users rather than tackling the issues of bringing those data sets together?

 

The Virtual database concept has been introduced in various other threads by various users but not on a specific thread to my knowledge. I believe we all know the problem when we first started our research of the my line & my wifes line probably followed by the Smiths of Ohio etc, I know I do. So what can RM and other programs do to facilitate users towards one Dataset?, should they even care or continue to help users maintain smaller differing datasets?

 

Named Groups have helped with larger datasets but it would seem to me that another database change to include Tags would seem to have some virtue.

[Laura]

Advantage in maintaining separate databases = none

When Family Origins introduced user defined facts, I created one named !Family Groups with the description enabled.

Every person in my database has that fact. In the description, I enter which family lineages that person [by blood, spouses, spouse's family members] is connected to.

The introduction of Color coding and Groups didn't replace the usefulness of the user defined fact.

I know instantly which family groups a person belongs to by looking at their record in Edit person or the Timeline view. I can also use the fact as a filter for Color coding, Groups, or exporting partial gedcoms.

Another possibility is to add Master sources and use Multicite to add that source to selected people's General [Person] source. Then the Master sources could be used as I use my user defined fact.

I am not in favor of RM adding a bunch of tags that will not be imported into another program as TMG users have found happening to their dismay.

[Jerry Bryan]

I am not in favor of RM adding a bunch of tags that will not be imported into another program as TMG users have found happening to their dismay.

 

I totally agree, and I think user defined facts are a much better way to go than tags such as those that are supported by TMG.  However, ....

 

If I understand correctly, TMG users have encountered great frustration in trying to replace tags in TMG with user defined facts in RM. That's because it's easy to assign a tag (or maybe a value to a tag - not sure of the details in TMG) to a bunch of people in TMG, all in one go. But adding the same user defined fact to a bunch of people in RM all in one go is essentially impossible unless you use an outboard mechanism such as an SQLite script.  For example, Laura is very lucky (and very smart!) that she decided a long time ago to add her !Family Groups fact to every person in her database. If she had to do it starting today and starting from scratch, I'm sure she would find the task overwhelming. But now that the fact is there, as she says it's extremely useful because it can be used with People View, color coding, creating groups, etc.

 

So as to Vygers question of "What could Rootsmagic do in your opinion to overcome the challenges of working in a very large database?", I would suggest that bulk addition of user defined facts would be hugely useful. For example, what if you could bulk add a user defined fact to every descendant of John Doe? And what if you could bulk add a (presumably different) user defined fact to every descendant of Samuel Smith (a common descendant would have both user defined facts). The benefits to managing large databases would be enormous.

 

Jerry

[Jerry Bryan]

What could Rootsmagic do in your opinion to overcome the challenges of working in a very large database?

 

There are many things that could be done to improve things. One of the chief things would be to allow two or more different people to work on the same database at the same time. An obvious example would be to allow husband and wife to work on the same database at the same time from within the same household. That's because we are forever getting questions on how best to split or how best to join databases for two spouses who are both working on family history.

 

Perhaps less obvious would be to allow multiple researchers to work on the same database at the same time while not living in  the same household. I make the distinction because the technical challenges become much greater when the database is in the cloud.

 

It would be easy to get into a technical discussion of how to accomplish the ability of having multiple researchers work on the same database at the same time. Indeed, FamilySearch Family Tree might serve as a model, except having a private common tree for a few researchers rather a public common tree for the whole world as FamilySearch Family Tree is trying to accomplish. Having said that, I think FamilySearch Family Tree is a cautionary tale of the technical and policy difficulties associated with the sharing of databases.

 

Jerry

[Laura]

Jerry, if I was starting today with adding that fact to my 17,000 + database, I would do it. It might take me a long time to finish it, but I would eventually get it done.

I have to maintain the fact when I add new people and find a person is also connected to another family lineage which happened not long ago.

In the meantime, I would use Master sources and Multicite. In fact, that would be my starting point for which lineages to add to the fact if I was starting from scrarch today.

I have some user defined facts that it would be useful to be able to bulk add the fact to multiple people. But, most of my user defined facts require at least entries in the description field to be useful.

Using my family group fact as an example, for a bulk add fact to be useful, I would have to have a separate fact for each family group instead of 1 fact and adding multiple family groups in the description field as Johnson, Lewis, Smith.

[Vyger]

Advantage in maintaining separate databases = none

When Family Origins introduced user defined facts, I created one named !Family Groups with the description enabled.

Every person in my database has that fact. In the description, I enter which family lineages that person [by blood, spouses, spouse's family members] is connected to.

The introduction of Color coding and Groups didn't replace the usefulness of the user defined fact.

I know instantly which family groups a person belongs to by looking at their record in Edit person or the Timeline view. I can also use the fact as a filter for Color coding, Groups, or exporting partial gedcoms.

 

For once I am in complete agreement, as you know I try to avoid workarounds but yours provide a Tag and maintains gedcom compatibility, good one.

[Vyger]

So as to Vygers question of "What could Rootsmagic do in your opinion to overcome the challenges of working in a very large database?", I would suggest that bulk addition of user defined facts would be hugely useful. For example, what if you could bulk add a user defined fact to every descendant of John Doe? And what if you could bulk add a (presumably different) user defined fact to every descendant of Samuel Smith (a common descendant would have both user defined facts). The benefits to managing large databases would be enormous.

 

Colour coding is not versatile enough for this need but the bulk addition of a hard coded RM decided custom fact could be easily programmed. There would, of course be calls for the Undo button from those who didn't keep backups but having said that the bulk removal of such an RM decided custom fact from all those in a Named Group wouls also not be too challenging.

[Jerry Bryan]

In the meantime, I would use Master sources and Multicite. In fact, that would be my starting point for which lineages to add to the fact if I was starting from scrarch today.

 

That's really a very clever idea. When planning for future enhancements, Multicite is a model that that the RootsMagician might keep in mind should he ever decide to address this need that we are talking about. You can certainly search and color code and make groups just fine from values you have set with Multicite. About the only thing you can't do with Multicite that you might want to do is to make columns in People View based on Multicite values.  Well, there is also the problem that citations can't be made private so that if you use Multicite to "tag" people then the citations show up in reports. But it's still an intriguing idea.

 

Jerry

[John_of_Ross_County]

Color coding that propagates back through ancestors or forward through descendants wipes out any existing color coding when it intersects with someone already set to some other color.

 

What other options could be used?  Maybe setting the conflict to a third color?  Or something else?

 

Bulk addition of of custom facts as suggested by Vyger would not have this problem for differents fact types.

[Jerry Bryan]

Color coding that propagates back through ancestors or forward through descendants wipes out any existing color coding when it intersects with someone already set to some other color.

 

What other options could be used?  Maybe setting the conflict to a third color?  Or something else?

 

The following is sort of a joke, but I distinctly remember that it really happened.When color coding first came out, a user color coded some of the people in their database red and then color coded a different group of people as blue. There were people common to both colors, and the user asked why such people didn't end up being color coded as purple.

 

Jerry

[TomH]

If one group was blue and another green, then applying yellow to both would flip them!

[Jim Byram]

Jerry wrote...

 

The following is sort of a joke, but I distinctly remember that it really happened.When color coding first came out, a user color coded some of the people in their database red and then color coded a different group of people as blue. There were people common to both colors, and the user asked why such people didn't end up being color coded as purple.

 

Actually, you could do that in TMG for an accent. The purple is a "conflict" color used when two or more conditions of an accent are met for a person.

 

For example...

You have an accent for decendants of different people.

blue - 'is a descendant of Person A'

red - 'is a descendant of Person B'

purple - your setting for the conflict color

An individual who is a descendant of both Persons A and B would be colored purple.

 

The discussion above is confusing regarding TMG vs. RM.

 

TMG tag types and tags are perfectly equivalent to RM fact types and facts and are imported (except for the primary role sentences for the RM default fact types).

 

You seem to be referring to TMG flags which are single character attributes and are not imported. Some people have used RM fact types/facts as substitutes for the TMG flags.

[Jerry Bryan]

 

You seem to be referring to TMG flags which are single character attributes and are not imported. Some people have used RM fact types/facts as substitutes for the TMG flags.

 

My bad. Thanks for the correction in the terminology.I think I had the correct concept but the wrong terminology. It is hard to accomplish the same thing in RM that you can accomplish with flags in TMG. You can accomplish the same thing with RM using user defined facts. But it's much harder in RM because there is no way to bulk add a user defined fact to a group of people. You have to add the user defined facts one at a time within RM, or else bulk add them outboard of RM by using an SQLite script.

 

Jerry

[Jerry Bryan]

I just had an Aha! moment that turned out to be false. I created a play data base that was a copy of my production database. In that database, I created a user defined fact called Mycolor, and the only thing enabled was the Description field. I created a dummy person, and I added the Mycolor fact to the dummy person with the Description field set to  purple. (It could have been any character string - it wouldn't even have had to be the name of a color). And here's the Aha! moment that didn't work. I shared the Mycolor fact with everybody in the database.

 

Sharing a fact with everybody in the database can be done all at one go. I could have been much more selective because the full power of the Mark/Unmark dialog is available when sharing facts. I was hoping to get the effect of bulk adding a user defined fact to a bunch of people all at the same time.

 

But sadly, RM's shared facts let me down again by once again not acting enough like real facts. The Description field of "purple" only showed up in People View for the dummy person who had the real Mycolor fact, not for all the other people in the database who were sharing the Mycolor fact. Doing searches with RM Explorer looking for people a Mycolor fact with a Description field of purple found only the one dummy person with the real Mycolor fact, not all the other people who were sharing the Mycolor fact. Etc. So my Aha! moment was a complete flop. So close, yet so far.

 

Jerry

 

[Vyger]

But sadly, RM's shared facts let me down again by once again not acting enough like real facts. The Description field of "purple" only showed up in People View for the dummy person who had the real Mycolor fact, not for all the other people in the database who were sharing the Mycolor fact. Doing searches with RM Explorer looking for people a Mycolor fact with a Description field of purple found only the one dummy person with the real Mycolor fact, not all the other people who were sharing the Mycolor fact. Etc. So my Aha! moment was a complete flop. So close, yet so far.

 

Jerry

 

 

In my opinion incomplete programming and completing of previous RM enhancements remain a clear and present part of this problem with what Jerry cites being a clear example.

 

Named Groups, although probably never to become dynamic, are a real help with larger databases but more functionality needs to be achieved to allow any and all RM tasks to be performed solely within specified Named Groups, again IMO.

[Renee Zamora]

This is the fastest way I would add a fact to a lot of people inside RootsMagic.

 

I would create a blank database with one person without a name, only the fact and information I wanted attached to it.  Then I would open my database so both are side by side. Then Drag n drop the "fact person" to each person in my database that I wanted to have that fact. Making sure to check the option confirming they are the same person, so they auto-merge during the drag n drop. 

[TomH]

This is the fastest way I would add a fact to a lot of people inside RootsMagic.

 

I would create a blank database with one person without a name, only the fact and information I wanted attached to it.  Then I would open my database so both are side by side. Then Drag n drop the "fact person" to each person in my database that I wanted to have that fact. Making sure to check the option confirming they are the same person, so they auto-merge during the drag n drop. 

Of course, we are all anxiously awaiting the day that Memorize Fact and Paste from Memory along with Copy Fact to Group come off the tracking system. My fast method is to use the SQLite query Copy Fact to Group. I imagine a user interface for it within RootsMagic should not require much developer time.

[Vyger]

Of course, we are all anxiously awaiting the day that Memorize Fact and Paste from Memory along with Copy Fact to Group come off the tracking system. My fast method is to use the SQLite query Copy Fact to Group. I imagine a user interface for it within RootsMagic should not require much developer time.

 

Thanks TomH, I have taken the liberty of quoting this more than 4 years old wish on the Productivity thread in an effort to maintain relevant issue logging.