> It seems to be a single table. Yes, so far. We may want to add a link to a relationship_type table but that does not change the general concept.
> I do not some sort of ?external key (fk_relative??) Yes, fk_relative *can* point to another identity in the database. It's *either* fk_relative OR relative_name and relative_dob but not both. > One of the major bugbears of my system is the inability to import family > history data from within the database from related persons, although when I > set the tables up which I've shown you before (and enclose below), they were > normalised to do so, I never got it finished. > > This has caused endless unnecessary repeative copying from one instance of my > program to another - instead of being able to have an import wizard come up > with all related family members and let you click on a checkbox to include a > particular history problem in the persons notes you are working on. Ah, *that* is how I know Richard talking design :-) > Have you included this ability in your table design? I *should* think so. For one thing we have the ability to store links to relatives (independant of family history). Also, we can directly *point to* a relative *from* fHx. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
