Hi!
Jumping in a little late on this topic I would still like to add some
small notes to the contacts/unique/duplicate question. I will just qoute
the bare minimum, without any originators mentioned (working with
digests in Ilohamail is as complicated as in other Clients ...).
The problem discussed is a very common problem for address databases. I
can tell so because I'm currently designing such a database for a large
customer (and have done so before several times).
>----- Original Message -----
>
>> I'm not convinced enforcing a unique name field has a net-positive
>> effect on usability. I like fields to be free-form as much as possible,
>> so that users have the maximum freedom to use the feature as they
>> [...]
My experience is to have as less restrictions as possible. If in doubt,
make this customizable (a toggle which makes the fields unique - this
then clearly has to be in the business logic, not in the database). Only
have restrictions on fields where you need them for technical reasons
(side remark: this is not true for all types of databases).
Try not to mix the person (physical representation, unique) with the
name/address etc. which is not unique in may cases. We had to discuss
cases where name and address were identical but we had to persons.
>It all started because I found it confusing that if I import contacts, I may
>end up with multiple similar entries that look alike and have to browse
>through them to find the right one. So, my idea to make name unique
Import is an extremely difficult topic. If you have a clean database then
import should be no problem as the source should have taken care about
uniqueness. If you import data into an existing database you are always
in trouble.
- How to indentify duplicates reliably (see above)?
- Should existing entries be updated (you import new data)?
- If you update, will you update only added information? Or all fields?
- If you missed duplicates, how to resolve them afterwards?
- What about the multi-user environment where you might have the same
person (with the same display-name) several times?
- ...
>Basically, I think it was Dean who said that some such questions could be
>added to the add or import dialogue instead of changing the database.
I would propose that as well. Don't make the display name unique, but
tell the user when an import would lead to a duplicate display name.
Then the user should be able to change this to a unique display name.
BTW: Maybe you should consider having more than two "telecommunication
addresses". We decided to have a combined list of Email-Addresses,
IM-Addresses etc., similar to
telcoaddr {
id int,
type text, # even better: ref to another table
addr text
}
For sending mail you could then pick all addresses with type "Email".
I would very much like to do some part of the coding on this topic, but
right now I have almost no time at all. Maybe I will find some time to
make some code proposals, but don't rely on this ;-)
Best wishes
Elmar
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ilohamail-devel mailing list
Ilohamail-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ilohamail-devel
