Home/ Questions/Q 7722903
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T04:18:34+00:00

I have two tables, Users and People, both of which share a common attribute,

  • 0

I have two tables, Users and People, both of which share a common attribute, email address, of which they should be allowed to have many email addresses.

I can see three options myself:

  1. One link table with redundant columns:

    • Users [id,email_id] and People [id,email_id]
    • EmailAddress [id,user_id,person_id,email_id]
    • Emails [id,address,type]

  2. Two link tables without redundancies:

    • Users [id,email_id] and People [id,email_id]
    • PersonEmail [id,person_id,email_id]
    • UserEmail [id,user_id,email_id]
    • Emails [id,address,type]

  3. No link tables with redundant columns:

    • Users [id] and People [id]
    • Emails [id,address,type,user_id,person_id]

Does anyone have any idea what would be the best option, or if there is any other ways? Also, if anyone knows how to implement or feel it is better to have link tables without the generated id column please also specify.

Update: a User has many People, a person belongs to a User

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First off, the relationship between user and e-mail is 1:N, not M:N, so in any case you don’t need the “link” table EmailAddress.

    You need to decide which of these possibilities is true for your application:

    1. User is always person.
    2. Person is always user.
    3. There can be a person that is not user and there can be a user that is not person.

    Option 1:

    Assuming the option (1) is the correct one, the logical model should look like this:

    enter image description here

    The symbol between Person and User is “category”, which at the level of the physical database can be implemented either:

    • as a “1 to 0 or 1” relationship between separate tables Person and User,
    • or a single table containing both person and user fields, where user fields are NULL for persons that are not also users.

    If you have…

    • many user-specific fields,
    • there are user-specific foreign keys,
    • new kinds of persons could be added in the future
    • and you don’t need to squeeze-out every last drop of performance,

    …choose the implementation strategy with two tables.

    If there are:

    • relatively few user-specific fields,
    • there are no user-specific relationships,
    • low “evolvability” is acceptable
    • and performance is of high importance,

    …choose the implementation strategy with the single table.

    Similar analysis can be done for each of the remaining possibilities…

    Option 2:

    enter image description here

    Option 3:

    enter image description here

    • 0