Skip to content
Advertisement

Primary key requirements

Is it a good idea to store phone number as a primary key on RDBMS? They are unique to nearly all of us. But my friend suggests it is not a good idea because of the following reasons.

  • What if two people in a family share a phone number?
  • What if a person does not have a phone number?

What are your insights, please let me know!.

Advertisement

Answer

I’d be against this idea, generally for reasons:

  • It is personally identifiable information and I’d recommend using it with caution if you’re bound to GDPR. Some users might ask you to not use their phone numbers. It might later be required to hash or mask part of the phone number, or even completely get rid of it.

  • Value depends on user input even it is validated. There are several services which lend you a phone number for validation if you’re not in the target country of the validator.

  • A schema needs to be defined of the phone number if it will contain country code, parentheses or spaces.

  • There should be a validation to prevent duplicates and null values.

In summary it is not a good idea to use a field which has a dependency to external facts. As others mentioned, using an autogenerated identifier for the ID and non-unique index for the phone number seems like a better approach.

User contributions licensed under: CC BY-SA
4 People found this is helpful
Advertisement