When importing /matching with FamSearch many Places are imported in different
Schreibweisen.
Ich merge sie regelmäßig mit “merge Places”.
Wie kann ich erreichen, dass diese merges auch für meine weiteren Databases gelten?
Mit “import Lists” werden sie zwar übernommen; jedoch werden sie mit den bestehenden gemischt.
So kann die Arbeit wieder von vorne beginnen
Wie kann man erreichen, dass eine an einer Stelle gepflegte Place-List die jeweils aktuelle Place-List beim Import ersetzt?
This can be similarly applied to preserve your updated Place List (you’ll still need to merge places from people imported afterwards).
Generally, you are encountering the drawbacks of splitting trees out to separate databases. Most users recommend against making all that extra work for yourself, when separate trees can be easily maintained all in one database.
Deine Empfehlung ist also, eher nur eine Datenbank zu haben?
So sind Places, groups, rules etc einheitlich an einer Stelle.
Welche Strukturelemente bieten sich an, um die Trees zu gliedern und zu filtern?
Da kommen wir wieder an die Schwachstelle von RM im FS-Browser, wo nur wenige Filter möglich sind.
I also generally recommend not spitting an RM database into multiple databases. But that doesn’t mean there aren’t sometimes some good and valid reasons to do so. One very obvious example is if you are doing genealogy for customers, you would want the data for each customer in a separate database.
To me, the main other reason for splitting an RM database into separate databases is simply to get better filtering than you can get in a single database. We could quibble about whether RM inherently does a a good job or a great job or a not so good job or a not so great job of filtering in a single database. My favorite example is Ancestry rather than FamilySearch, but I would like to be able to filter an initial upload from RM to Ancestry by a group. The group would be the people I’m willing to make public in Ancestry. But RM doesn’t support that kind of filtering.
So I would summarize by saying that I usually recommend not splitting a database and I don’t split my database myself. But there really are good and valid reasons sometimes to split a database.
I am sure we are just not understanding which FamilyTree features and filtering you feel works better (for You) in separate databases. Reduced numbers of people/families in a database certainly shorten times for access, exchange, sorting and organization, ETC. RM has improved some features, to compensate, like Groups - Color Code - Saved Criteria (Rules) and others.
Just an aside about preserving past work surrounding Places and Rules and Color Coding and such: When one cleans up and makes a copy of the normalized and improved database, then deletes most or all people… that can be backed up and become the (template) start of each new set of imports or dragNdrop… and then as more improvements to rules, color codes and the like can become an even newer, fuller (base or default) template database. All, with backups to revert to, if the process goes haywire.
