"DBUsers" as related file to "People" - best way?

[cmartin]

In my inherited database I have seperate db files for all different types of people: coordinator, investigator, site investigator, etc. This is yuck-o. I am trying to get all of the basic person info (name, title, degree, etc.) for each of these groups into one file: People. Also, I am trying to build a custom login system. I am creating a file called Users to facilitate this second task. Should the Users file have a PeopleID foriegn key or should the People file have a DBUser foriegn key? I currently have the PersonID foreign key in Users but I am having a hard time creating a value list containing names of the users. Also, along these same lines what about all the info that is not person related but rather person type related. Should I create separate files for that kind of stuff or just have bunches of blank fields?

[Kurt Knippel]

I would keep your "login" and "contact" DBs totally seperate. They have totally different purposes and generally will not contain any of the same information.

[cmartin]

My users are a subset of my contacts. Many of the people who are already in the database in some capacity will be users. For example, we have contacts called coordinators, who will be users in the future, however, they can only access those records where they are designated as the coordinator.

[Kurt Knippel]

Matters not one bit. Keep your login and contact list seperate. It'll make life much easier on yourself.