Nick Matthews wrote: > > I didn't intend to comment on this thread because my project is at a > very early stage, there's no functional program yet but there is code > and the beginnings of a practical (I hope) database design at > thefamilypack.org - but that was such an actuate description of what I > am trying to achieve that I feel obliged to point it out. > > In particular, you mention standing data; I think this is an area where > open source collaborative efforts can really be made to work. I'm sure > that anyone who has spent a few years on their family tree will have > become expert on some small areas of local history and geography, if > there was a simple way to contribute that expertise, without commercial > interests taking advantage, then I'm sure it would happen. FreeBMD and > friends are a good example of what can be done. > > Unfortunately this will be the last piece in what has become a very > large jigsaw in designing such a system - but a lest it is being thought > about at the beginning of the process. > > If anyone does go to the trouble of looking it up - I should point out > the the database design only includes the minimum necessary for the > program code that is being written. So if you have a question starting > "Why doesn't the database include ...." the answer is almost certainly > "No, not yet, but ...". If you intend being "Able to compare and transfer data directly between databases" you need to think in terms of an import and export in a format which directly mirrors the data model. Presumably you're thinking in terms of XML for such an external representation. Can I suggest that rather than start straight in with an SQL database & hard code you prototype with XML? This suggestion arises from personal experience of projects where XML was the medium of data exchange between partners and getting the right expression of data in XML was a big help in data modeling. You might then find it more convenient to store data as XML fragments rather then conventional database columns. Also, you have integers as PKs in the database design. This is the most efficient way to glue the tables together internally but if it's to meet the data exchange aim you need something in the external representation which will be unique across databases such as UUID/GUIDs. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On 21/05/2011 11:39, Ian Goddard wrote: > > If you intend being "Able to compare and transfer data directly between > databases" you need to think in terms of an import and export in a > format which directly mirrors the data model. Presumably you're > thinking in terms of XML for such an external representation. > As currently designed, the entire database is a single SQLite3 file. This has a number of advantages, not least, it's easy to move about and copy and we're not constrained by memory size since it doesn't have to be read in first (although I am a bit concerned about the file size once we start putting scans and photos into it - I may consider splitting these off). The program can transfer data by connecting one database to another and just transfer the records you are interested in. I will be adding GEDCOM export/import for transfer to/from other programs, but I am not anticipating "round trip" accuracy, the idea will be to create a new database from a GEDCOM file and then attach it to your working database. > Can I suggest that rather than start straight in with an SQL database& > hard code you prototype with XML? This suggestion arises from personal > experience of projects where XML was the medium of data exchange between > partners and getting the right expression of data in XML was a big help > in data modeling. You might then find it more convenient to store data > as XML fragments rather then conventional database columns. > Although the basic design is (already) a relational database, one of the key elements within it will be the "reference document" - this document holds the raw data that is used as the source of all facts used. They can be transcriptions of censuses, certificates or parish register entries or summaries of other documents, emails, letters, conversation transcripts or the musings of the researcher. These documents will (eventually) be in XML form so you can link words and phrases to individual records. In effect, the researcher is breaking a document down into atomic parts and then coalescing the parts of a number of documents into a narrative. This sort of approach can become tedious and so needs lots of help from the computer to be workable, which is what I am working on at the moment. Since it is always possible to add more documents which support (or not) the current conclusions - you can work in the opposite direction and start with a tree and add the documentation in afterwords. > Also, you have integers as PKs in the database design. This is the most > efficient way to glue the tables together internally but if it's to meet > the data exchange aim you need something in the external representation > which will be unique across databases such as UUID/GUIDs. > I've yet to be convinced on the usefulness UUID/GUIDs, I'm never sure what they're supposed to show. Facts should be linked to their source and conclusions linked to the person who made them - anything else seems to vague.