gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Questions re database schema:street:address:urb:count


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Questions re database schema:street:address:urb:country
Date: Wed, 8 Sep 2004 11:15:15 +0200
User-agent: Mutt/1.3.22.1i

> 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.
Correct.

> 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.
Sure enough.

> 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 
> unique?
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?
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 
> addresses.
I agree.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]