Jeremy Erwin wrote:
>
> >
> >One thing I am confused about. Why are dates seperated in the DB into
> >day,month,year? Why not just have a date field? DB level queries would be
> >easier with just a date field and many DBs support dates are field types.
> >
> >One other thing (and I may just be missing something), 'state' and
> >'continent' do not appear to be used anywhere. And I am not sure of the need
> >for 'City', 'County' and 'Country'. Can we not dynamically build these from a
> >'unique' query on the 'place' table at startup? Then use auto-completion in
> the input boxes to avoid the need for abbreviations?
>
> In genealogy, one often needs to use alternate calenders --
> gregorian, julian. One also needs to store information about precison
> (day, month not known).
>
> Ideally, all places would be stored as longitude/latitude, since
> cities expand and the borders of counties change. (I have an ancestor
> who was supposedly born in Ithaca in 1803. Throughout the period
> 1800-40, that area has been included in three different counties.
> Before circa 1815 Ithaca did not exist as such.) It would still be
> useful to search specifically on county.
>
Like Jeremy mentioned, the two things that we are trying to address with
having the year, month and day as separate fields are multiple calendars
and date uncertainty. You'll notice that where there is a triplet of
day/month/year fields, there is also a calendar ID field. One of my
friends is in Rabbinical school, so the need to store at least Hebrew
dates was quite obvious to me. From there, an extension to other
calendars - such as French Revolutionary, Muslim or Chinese, for example
- was only natural.
To handle the uncertainty in our record keeping, we are allowing the
marker 0 for any of the day/month/year fields to indicate an unknown
quantity. In my own research I've found quite a few records that list
only a year for a birth or death. This level of granularity allows us
to store the part of the date that we do know without getting warnings
about invalid data.
As for the location fields, Jeremy hit on the two biggest reasons again
- places change names over time, and the ability to search more easily
by any of the place names. This part of the database can probably be
improved, but this was what I could come up with. I would like to have
autocompletion for abbreviations as well, so I've tried to make some
accommodation for it. I hadn't thought of using long/lat coordinates,
but I like the idea. My only concern is that we would need to include a
bit of slop to use them for many records.
--
Sean Lamb --- [EMAIL PROTECTED] Software Engineer
while( ) { s/$badcode/$goodcode/g; }
"A day without laughter is a day wasted." -- Groucho Marx
_______________________________________________
Genes-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/genes-devel
