[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Questions re database schema:street:address:urb:count
Re: [Gnumed-devel] Questions re database schema:street:address:urb:country
Wed, 8 Sep 2004 11:15:15 +0200
> But if you mean "why offer Town B" at all even when "Lakeshore / Town
> B" has still to be created for the first time? As a user keys in
> "Lakeshore" the closest match be "Lakeshore Road / Town A" but that
> is no good. The user will want to signal "yes, street.name truly is
> Lakeshore Road, but not Town A" --- a new row will need to be created
> for this street name (even thogh the street name may already exist)
> because a different urb will need to be designated from among
> existing entries in the urb table *or* from a new entry.
> One's own local urb can always be offered as the default, but just
> because most patients live in Town A should not mean that I can't be
> offered Town B and Town C if they are already in the system.
> Vancouver is only 12km x 20km and is bordered by 4 other "Towns" with
> many people getting medical care across these boundaries. Even if
> some other Gnumedder lives in isolation, or with a "pure" local
> practice with 99% of their patients from a single urb, that gnumedder
> will, when inputting addresses, be inputting other urbs for the
> addresses of organizations and visiting patients.
> I note also in the street table some "unique" constraints on each of
> id_urb, name and postcode but is is the *combination* that is
The constraint is on the combination.
> A Canadian postal code specifies to the level of one or two
> city blocks, either the "even" side or "odd" side of the street which
> means that within the same town, a street that runs the length of the
> city could have (I am just guessing here) 30 or 40 postal codes and
> so would result in 30 or 40 rows in the table, yes?
> Sort of what I thought... suburb seems like it can be used "loosely",
> for whatever function it seems to best serve, in those settings
> where "suburb" may not be tightly coupled to precise physical
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346