Re: Designing a structure for a personal database

Marco wrote:

> On May 6, 4:22 pm, David Segall <da...@[EMAIL PROTECTED]
> wrote:
> 
>> Thanks Arved. I agree that the application probably reduces to a
>> many-to-many relation****p between persons and businesses in one table
>> and locations in another and that does lead to the difficult and
>> probably off-topic question of designing a GUI to represent that
>> relation****p.
> 
> Not impossible to implement in a user-friendly way: on the edit form
> of one person the user sees the list of addresses and the "+" button,
> which leads to the address entry form. After the user clicks "OK" on
> the latter, the application checks whether the address already exists
> or not (even by applying some euristics, e.g.: "High St." is supposed
> == to "High Street"), and proposes to select among possibly equivalent
> addresses. New address is only added (and a record on the bridge table
> with it) if no existing one exists or none is selected by the user.

Potentially some form of autocomplete might be worth considering, at least
for address. Nothing new - I believe GMail does it for addresses. Street
name is likely the most authoritative field; other fields are either not
selective enough (like unit number) or have different possibilities (like
municipality).

Something like what you suggest clearly has to be available for the
general
case, or where autocomplete fails due to typos ("how the hell d'you spell
that anyway?").
 
[ SNIP ]
AHS
-- 
* change 'two' to '2' to email me