On Monday 18 December 2000 14:17, you wrote:
> 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.
>
I understand this now. It will be interesting trying to work out what the
ordering sematics are between multiple records using different calendars :-).
> 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.
>
I can see this point. Very many of my records have month and year but no day
and many have just a year.
> 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.
>
I am still a little troubled by this. I can see the reason for not linking
the state table to any of the address records. But I can't see which of the
fields you would use the 'state' records to auto-fill. Because 'place'
records have 'city','county' and 'country' so which field in a dialog would
auto-complete to 'state', the 'county' or the 'country'? And when would you
use the 'Continent' records?
So the question in my mind is why not auto-complete in all fields. The values
for auto-completion could be gathered from single pass of the database at
startup. That way if you where entering the small surname over and over again
(likely I guess) it would be auto-completed for you.
I think I must be missing something. I guess that using seperate tables to
hold the auto-completion items like 'State' may aid performance in very large
databases.
Confused.
Richard
> --
> 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
_______________________________________________
Genes-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/genes-devel
