Designing a New Genealogy Program


Since retiring in 1999 and catching the genealogy bug in 2001, I have often considered writing my own genealogy program. I even started coding one back in 2008. But I soon remembered that coding without some clear idea of your ultimate goal is not a good idea.

So, with that false start in the back of my mind, I have decided to revisit the idea of developing a genealogy program from scratch. To this end, I will start by listing the technologies I would like the software to employ, the features that I would like the software to include, and any organizational issues that need to be addressed up front.


Ideally, the project will be made up of a core team of at least two like-minded developers. In addition, a small advisory group, whose job would be to provide feedback to the developers, should be brought on board from the very start. Later on, the role of this group of individuals might be expanded to include beta testing.


After doing some legwork, I have decided that the new program will be a Windows desktop application built on the following architecture:

  1. Microsoft Visual Studio 2005/.Net 2.0/VB.Net
  2. SQLite/ADO.Net 2.0 Provider for SQLite from sourceforge


The following set of features should be included in the program at a minimum:

  1. Support for the GenTech Genealogical Data Model. This approach will allow users to make assertions, which the program will evaluate (based on exactness/completeness and source surety) as part of constructing a presentation. For example, if one asserted Birth Date for an individual is Jan 1911 with a high degree of surety, and another asserted Birth Date for an individual is 13 Jan 1911 with a lower degree of surety, the program will present the former. How the program draws and presents its conclusions must be configurable.
  2. A mechanism to allow 3rd parties to add program functionality (reports, tools, etc.). Think WordPress Plugins or Firefox Add-ons. All reports (including the generation of web pages) will be provided via an Add-on.
  3. UNICODE character support.
  4. Provide location-to-location relationships. i.e. Ross, Butler, Ohio, United States was once known as Venice, Butler, Ohio, United States.
  5. Provide support for partnerships (i.e. same sex marriages).


3/5/2012 – I have purchased a license for SQLite Expert Professional and have begun work on the database design. Anyone who wants to participate in this phase of the project should drop me a line.


Entity-Relationship Diagram

Above you will find the start of this effort. The database structure will allow for same-sex marriages (partnerships) as well as partnerships that consist of more than two individuals. I will post updates to this ERD as I make progress. The Entity-Relationship Diagram was created with SQL Developer.

7/31/2013 – Begin work on the Database class. Also need to come up with a name for the software.

8/2/2013 – A name has been chosen for the application (will keep secret for now pending acquisition of a domain name). Database class from LTools has been adapted to work with SQLite. tRelatedLocation has been added to the database schema, thus satisfying requirement #4. Work on building the application infrastructure has begun.

8/21/2013 – Have gone thru several iterations of the ERD, finally settling on a simpler version (see above). Several supporting entities (tTags, tAssertionType, tSourceType, tSurety, tRelatedLocationType) have been left out in order to simplify the diagram. Coding is continuing. Below you will see a screenshot of the app’s main form. Nothing behind it is working yet. As you can see, UNICODE text is supported.

Main Form

Main Form

Comments are closed.