Hi Darren,
Thanks for posting this to the list. I haven't included your
conversation with Dave in this reply, to keep the posting short.
A few thoughts...
There already exist a number of systems which store genealogical
information in relational databases, for display by wikis or in more
traditional genealogical style. I have been using the open-source
phpGedView (see phpgedview.sourceforge.net or www.phpgedview.net) for
some while now, and use perl-gedcom utilities for various management
tasks and for writing the occasional one-off processing tool.
php or perl? Horses for courses, in my view. Both will do the job:
php, in my view, is better than perl for generating web pages on the
fly, and more widely used, though perl can do the job tolerably well.
perl has its own strengths, and if you're just creating a database
for genealogical data with your own front-end, perl would do it
perfectly well. But it's already been done.
phpGedView, GeneoTree, Oxy-Gen and other existing systems are all
designed to parse gedcom files and convert them to SQL databases. It
would seem to be more useful to contribute to existing open-source
systems that to start trying to write a new one for one's own use:
for example, phpGedView already provides tables which allow for
multiple families, aliases, source information and quality by
implementing the full GEDCOM structure.
I must admit, I do like your distinction between "first hand
experience", "assumed most likely considering X" and "just heard it
somewhere" as examples of differing quality of non-record-based
sources. GEDCOM 5.5 (still the de facto standard, and the
implementation on which this list is based) only has QUAY 0/1/2/3
(which it defines basically as "unreliable" / "questionable" /
"secondary" / "primary or evidence-based"), and these are neither
carefully enough defined nor sufficiently widely or consistently used
to be of much value except to the person ascribing the quality to the
source in the first place.
Regarding database implementations: I understand (as a software
developer myself) that there is a camp where PostgreSQL is strongly
preferred over MySQL, and the recent acquisition of the latter has
added fuel to the cause. But (imho) you're heavily overstating the
case to claim that PostgreSQL "is a much more reliable and better
quality DBMS, which all the savvy people prefer over MySQL". One
factor many people have to take into account is that many third-party
web-space providers also provide MySQL servers: users may not have
the choice. In my experience, they differ more in implementation than
in quality, and MySQL works perfectly well (and reliably) for the
sort of task genealogical databases require. It's widely-available,
well-supported, industrial-strength, scalable, and I like it :-)
Just my two-penn'orth...
/mike
On 29 May 2010, at 05:13, Darren Duncan wrote:
FYI, the following message is a quick private exchange between Dave
Patton and myself, where Dave had written me privately, apparently
in response to a post I made to this list in February of 2007 with
the same subject line; I am forwarding it in case my contained
brief suggestions on how to design a genealogy database would be
useful to others. -- Darren Duncan
