I’m not one who really enjoys writing code. In fact, I tend to avoid it whenever possible as it’s just not that interesting to me. That said from time to time I have projects to complete where no existing software quite meets my needs and writing my own makes the most sense. This summer I was in the midst of collecting information and publishing a large extended family directory.
Clearly, the best way to do this is to store the data in a database. Because relational databases are most prevalent, I already have quite a bit of experience with MySQL and I knew I wanted to eventually make the data available via a PHP web application I decided to go with a MySQL backend. The trick here is that families aren’t as relational as you might originally think. Families are really hierarchical data (parents, children, grandchildren, etc.) and relational databases have a hard time storing and recalling things based on these types of relationships. For example, a typical family query might be one for a list of all descendants of someone. As it turns out families aren’t the only hierarchical data people might try to store in a relational database. Any business database which shows managers and reporting personnel is also a hierarchical data set albeit usually with fewer levels and much less complication (no need to track divorces, remarriages, spouses, etc.)
I was able to find and read up on several methods for storing the relational information but the one I ended up using is that proposed by Rob Volk of SQLTeam where the expensive (computationally) hierarchical relationships are stored in two additional fields for each record (depth and lineage) with parseable separators between generations. The database is initially loaded through a series of several (expensive) recursive queries but then can be maintained through triggers when information is added or updated.
Comments are closed.