> /home/user/user1/user1.db [User1 will have table to hold contacts list]
> /home/user/user2/user2.db [User2 will have table to hold contacts list]
> .
> .
> .
> /home/user/userN/userN.db [UserN will have table to hold contacts list]

This would imply that you are writing an application where each user has
their own file structure (like a word processor would, for example). i.e.
the user logs in and runs the app, accessing their own files. If this is
the case, then yes, what you are suggesting is correct since the various
contact lists are isolated entities.

If, however, the users share the app and there is one data file, then the
normalization argument kicks in. In this case you would have two, or
possibly three tables. The first would contain all your user's details
(including, if appropriate, security information to allow the application
to authenticate them) One column would be a unique ID number, known as the
primary key. A second table would contain the contact details. One column
of that would be the id of the "owning" user (known as a foreign key). So
when your application wants to list a user's contacts it searches for only
those contacts that are "owned" by the user (i.e. the contacts whose
foreign key is the user's primary key).

It gets better! If, say, two users have the same contact then there will
be two entries in the contacts table and therefore two entries to keep up
to date. Let's say you want to be able to share contacts. Now what you do
is to have a primary key on both the users and contacts tables (I always
have a primary key on every table anyway) and a third table which contains
two columns of foreign keys, one for the user and one for the contact.
Now, each user can have multiple contacts and each contact can have
multiple users. In this case, I would probably include information in the
relationships table to control which user can edit the contact, but the
point is if, say, I had you in my contacts list and I shared that contact
with my wife, if your details changed and I edited them, my wife's version
would change too.

That, in a nutshell, is normalization.

I hope that helps, but like I said at the start, it depends how you see
your app working. Your original question implied that you would have 1
file and many tables in it (1 for each user) which would be wrong (well,
inefficient!)

I hope that helps.

-- 
Paul



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to