Richard Taylor wrote:
>
> I understand this now. It will be interesting trying to work out what the
> ordering sematics are between multiple records using different calendars :-).
>
The most logical seemed to be to translate every date within the GenDate
object to store the Julian Day as well as the native calendar date, then
sort on the Julian Day. IIRC, Julian Day 0 in the algorithms we've got
implemented is Gregorian January 1, 2048 BC. Regardless of when JD 0
is, this gives us an integer value to sort any date.
When a part of the date is unknown, it will treat that unknown quantity
as 1. For example, the native date May 1886 would sort to the same
position as May 1, 1886, and the native date 1965 would sort to the same
position as Jan 1, 1965.
>
> 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.
>
Leaving out State was probably just an oversight. It should
autocomplete just like city, county and country.
The Continent fields are for records where you know an immigrant came
from Africa, for example, but can't nail it down further yet. Some of
the records that I've found for my lines say something along the lines
of "came to America from Europe in ..." and I wanted a way to keep track
of this. I also envisioned an easier way to search for the immigrants
in a database (this search should probably be handled as an attribute,
but storing the from/to continents seemed a simple method as well).
Of the entire db schema, these location tables are the ones that I am
least sure about. The other suggestion that I've seen is in the mailing
list archive, but I think there's a better way than both of these.
--
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
