Front page | perl.gedcom |
Postings from July 2011
John Dobson wrote: > Darren: GEDCOM was not designed or ever used as a database design / > schema. It was designed and sill operates today as a database backup > format. Yes, and that's my point. At least my understanding is that GEDCOM is quite limited as to what kinds of information it can represent, and if you have any other kinds of information, you can't back up your entire database into GEDCOM. In fact my perspective on databases is that it is the external formats, fully documented and designed for interchange, that are the ones most important to be complete and comprehensive, and any separate format used natively to a program is just a performance optimization. So my main project here is actually a new interchange format, and having a better application is more incidental to that, as a reference implementation. If you are developing a serious genealogy database you better > have an option to import / export GEDCOM or your product will not passed > first base. Of course. The new format will accurately preserve the intended semantics of any data that GEDCOM or other genealogical formats can represent. But export depends on the information. Consider the new format effectively a superset of GEDCOM in capabilities, with the same limitations mapping the two as when you map ASCII and Unicode. > Ron: take a look at www.webtrees.net this is pretty much where things > are at for web based, collaborative genealogy products. Good to know. ------ Similarly, the main point of Muldis D is to be a comprehensive means to represent both relational data and database-centric code in a unified portable manner, like SQL but better; the DBMSs that implement it are second to this, and the initial DBMS that I make is meant as a reference implementation; the focus is on the language / data format, not on the program. -- Darren DuncanThread Previous | Thread Next