Use Email Address as Primary Key

Use email address as primary key?

String comparison is slower than int comparison. However, this does not matter if you simply retrieve a user from the database using the e-mail address. It does matter if you have complex queries with multiple joins.

If you store information about users in multiple tables, the foreign keys to the users table will be the e-mail address. That means that you store the e-mail address multiple times.

Thoughts on using email addresses as primary key

You should always have a unique integer primary key that has no business value. This is then referred to as a surrogate key.

You should store the email address itself in another field, frequently with an index so it can act as a key for lookups.

This will enable you to provide functionality that is based on locating the user based on using the email address for lookup. Any other functionality at that point then uses that records primary key for other operations, e.g. updating the users address.

Email-primary key, is it a bad idea?

Well, I guess the most obvious (not performance-related) reason is that users may want (or need) to change their email addresses.

If the email address is the primary identifier for user accounts this can get confusing pretty quickly.

From a domain modeling view, email-addresses are commonly handled as attributes of persons/users, just as a user name is. While user name changes can probably be reasonably not allowed, email addresses are rather likely to change at some point (user loses access to the account, the organization that maintained the account retires, etc.).

Also, an email address does not need to be eternally assigned to the same real-life person. joe@example.com could be owned by "Joe Miller" in 2005, "Joe Carlos" in 2013, and by "Joeberto Joeman" from 2020 onwards.

This possible need for change is IMO the main reason why email addresses don't make good primary keys.

Is it reliable to use email address as primary key/uid on Firebase Realtime Database?

You are using a very old version of firebase, you need to upgrade to firebase js 5.8.5.

Also no it is better to use the userId that you obtain are you authenticate a specific user. The main reason to use the uid is because it is unique for each user.

Check here :

Why use UID in Firebase? Should I use it

Is it a good practice to use email address as a primary key in many tables in a website system?

Not really. For any sizable data set, you'll end up wasting a lot of space and you'll take a performance hit when querying. In addition, if someone changes their e-mail (which you might or might not allow), you've got to change it everywhere.

A surrogate key to uniquely identify the user would be a much better choice.

Making email as primary key is bad idea?

Yes, it is a terrible idea. An email is something long (so your key is longer than necessary), and it isn't immutable. I've changed at least three emails in the last ten years (providers closed).

Laravel 5.2 - set Primary key to email instead of 'id'

Primary key is used for linking to other tables and string comparison is slower than int comparison.

If you store users information in multiple tables, the foreign keys to the users table will be the e-mail address.

That means that you store the e-mail address multiple times.
So, instead of using email as primary key use an auto-incremented primary key.

Email address as resource identifier in a REST API

I would use a user id. A person and their email address don't have a 1 to 1 relationship and they don't have the same life cycle, so using one as the identifier for the other is a bad idea.

People may have more than one email. Maybe they don't have an email account (it happens). Maybe they change their email. If you use the email address as the key, you might run into problems later on.

Use Email Address as Primary Key