[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Questions re database schema:street:address:urb:coun
Re: [Gnumed-devel] Questions re database schema:street:address:urb:country
Tue, 7 Sep 2004 00:42:40 -0700
> Crossing into town B the roadway may still bear the name Lakeshore
This is not really of concern to us, I tend to believe. For
all the GnuMed backend knows these are two "streets".
I was just setting a scenario where town B can choose to (re-)name
its "portion" of a street that continues across its boundary, and
that this name could later change again e.g. in honor of some local
person, without giving Gnumed trouble the way the backend has been
> When asking/entering/editing a new patient's address, they will
> typically say "I live at 2155 Lakeshore".
Why would they be offered town B ? The only reason I can see
would be that *most* patients of this practice live in B. If
the system doesn't know there's a Lakeshore Rd in B (due to
having other patients there) it won't know to offer B here.
If you mean "why would they be offered a lakeshore / Town B" combo I
agree, "no" if the combo did not already exist.
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
unique? 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?
When inputting a patient's address I would be happy for a phrase
wheel to narrow down the matches especially after I type several
letters of the street and a few letters of the city. However if the
user can only pick from fixed combinations of street/urb/postcode,
this may be painful: even when the street/urb combinations already
exist, the postcodes will often not. May there be some way for the
user to accept the match on the street/urb portion (to save having to
re-key it), but to indicate that a new row will be required to hold a
> I remain foggy on how OPERATIONALLY to use suburbs...
> tend to be defined by
> road and street intersections such as 1st avenue through 16th avenue
between Burrard St and MacDonald St. This may correspond to a range
of street building addresses, and a range of postal codes, yet
whichever administrative body defined the boundaries would not have
mapped them to specific ranges of addresses or postal codes.
I don't think we need to worry about that. We are providing
added value, not necessities here.
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