[Tutor] Dictionary Keys

[Magnus Lycka]

At 11:38 2002-08-06 -0700, Alan Colburn wrote:
>Basically, what do y'all tend to do when you are entering/saving=20
>information in a dictionary and, the way you've set up your script's=20
>parameters, you could conceivably create key:value combinations with=20
>identical keys (but different values)? I could think of many examples but,=
=20
>for the sake of concreteness, suppose a medical office is recording=20
>patient visits (patient's name, visit date, other information), using the=
=20
>patient's name as the key. The rest of the information is the key's value,=
=20
>perhaps stored in a list. If each visit represents a separate key:value=20
>combination, and a person makes multiple visits to the office, then ...?

But you would never use a real world value such as a name for
keys in your application or database. Would you???

http://www.ambysoft.com/mappingObjects.html and
http://www.thinkware.se/cgi-bin/thinki.cgi/CaseStudyUnbrokenSeries
are a few places that gives examples to why it's a bad thing to use
keys with business meaning in computer systems. They explicitly
discuss relational databases, but it's relevant in your python code
as well.

In short, even in you find keys that are unique, basically ANY value
with business meaning that could be used as a key might change sooner
or later. Social security numbers, phone numbers, names, article
numbers, zip codes... Having to change a key value is normally much
more work than to change just an attribute. Also, you might run into
situations where you realize that your key won't work. Phone numbers
get longer than you predicted or some people don't have a phone. You
internationalize your app and social security numbers don't exist in
some countries etc. If a value is used as a key somewhere in the
system, all other parts of your program that refer to that entity will
store that key. This means that redesigning a key field is much more
work than redesigning a plain attribute which is only located in one
place. (As you might guess, I've gone through this a few times.)

Returning to your example, one could imagine something like this:

persons =3D {}
...
# Creating a person
person_id =3D get_a_new_unique_id_somehow()
persons[person_id] =3D {'name' : "Will Smith", 'visits' : {} }
...
# Adding info on a visit
visit_id =3D get_a_new_unique_id_somehow()
persons[person_id]['visits'][visit_id] =3D (
  '2002-08-08 12:45', 'Dr Burns', 'Regular Checkup', 'Blah blah')

No, I don't think you will use hard coded values like
this in your actual program. ;-)

Obviously, your users won't be able to just type in the
key values in your dict here, since they are values that
doesn't mean anything. (Naturally, these abstract ids
should not be visible to the user of the system. They
should only see the data with a business meaning.) But it's
not very meaningful to discuss how this should be done
unless we consider how you store your data. The solution
will probably differ if you use a relational database or
a flat text file for instance. Either way, your program
will have to be able to handle the case where your user
doesn't know the exact value for a key, but will want to
do an approximate search, or browse your data. So you won't
save a lot of code in a real program on using real world
keys.

If you insist (suit yourself) on keying on business data
you'd get something like:

persons =3D {}
...
# Creating a person
persons["Will Smith"] =3D {'visits' : {}}
...
# Add info on a visit
persons["Will Smith"]['visits']['2002-08-08 12:45'] =3D ('Dr Burns',=
 'Regular=20
Checkup', 'Blah blah')



--=20
Magnus Lyck=E5, Thinkware AB
=C4lvans v=E4g 99, SE-907 50 UME=C5
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se