One Big Tree or One Per Direct Line?

My uncle has sent me family trees that he researched a long time ago without a computer. I am tryingto put his trees into GRAMPS.

Should I put everything into one big tree, or make one tree for each related family name?

My opinion: Everyone is related to everyone. Make it one tree.

As a side effect, this will save you a huge amount of time dealing with place records, and probably some time dealing with sources and citations.

4 Likes

If a family name is related they’re one tree, unrelated families can have a separate tree.

One tree, for all sorts of reasons, like place records, but also because they may have connections. And for those that interested, you can always create reports for their part of the family.

1 Like

I agree with @bgee. It will be easier in all regards to maintain one database. If at some point you want a report of just one branch of the tree, that can easily be done using a filter. A way to think about it… you could have your family tree, and you could have a separate tree for your wife’s family. But your kids family tree will be both your trees.

And who knows, branches of trees sometimes intertwine.

1 Like

A single tree is preferable because it is much easier to maintain the common areas: the Place hierarchy, common census & other broad application sources. Gramps makes it fairly easy to export a tree stripped to a branch.

However, when trees start to exceed about 30 or 40 thousand people, things can start to bog down on a basic computer.

But since it is FAR easier to segment than to merge, you can start with combined and break them if you hit performance problems.

My tree is only about half that size, but is growing.

Gramps is one of my two most demanding applications. My Windows desktop is nearly five years old. When I replace it, what aspects (CPU, memory, SSD etc) will affect the performance of Gramps most?

David Lynch

SSD for certain. Gramps is very drive intensive. Then probably memory.

Its least effective use of a resource is in using multi-core processors or threading. There are tricks you could do but nothing from a stock setup.

Consider you hardware retirement plan though. There are collaborative options just becoming available for Gramps. It is in the early days so the configuration process is still a bit daunting. But if you intend to work on Genealogy with a household member or a remote relative, you might want to make the old system a dedicated Gramps server.

Thank you for your replies. I am going to go with one big tree.

3 Likes

Note, for information. I still have a very old configuration (with gramps 5.1.4), as alternate backup, and for some local use (no network).

So, just an OS upgrade, using few ressources and having a recent kernel; The device has a pre-failure and old dated HDD of 40GB with 8341 PowerCycle (I know, this makes many on/off during around 20 years!), an half-Giga of RAM (physical memory) + some virtual memory via kernel module like zRam, and a Pentium 4 HT (so a pseudo-dual core)…

It can still run programs like gramps 5.1.4[1] or Libreoffice !!!
Sure, it still makes more noise than recent devices with SSD and
multi-tasks will not be very efficient, but you might be surprised.

For fun, and monitoring via ‘top’ this configuration, there is maybe some limitations with multiple consoles/tabs/tasks (e.g., many shells, desktops or users).

During a gramps session, the slow down (python3 pid) could be related to CPU (ie. computation with tools), but no major load average issues (often around 0.2 to 2.x max). Even to load a lot of gramplets, seems not to decrease a lot the memory available ! The limitation will rather around memory available during a long gramps session (e.g., many editions), more and less related to my configuration (ie. VIRT size actually sharable).

There is maybe, at least, one issue with the Galery gramplet (memory leak)? See also #PR140 on addons.

But this should not be a problem with any recent hardware and OS (with fair ‘shared ressources’).

[1] a Family Tree with 5000 people, 10500 events, 3400 citations,
1800 families, 1500 places, 1800 media objects, 1000 notes, 1700 sources, (~100 repositories and tags).

Also discussed in: