Database Reference
In-Depth Information
Of course, you want to save their e-mail IDs, don't you? Don't store them elsewhere
and use a join! It will be very inefficient. When there is user interaction and the user
profile changes, you don't want to update all the contacts in other tables. Moreover,
if you store the e-mail IDs in the same table, you also get a row-level isolation for
the cases where you are updating a profile and another process is also updating
it. If e-mail IDs are stored in a separate table, this might be harder due to the
distributed mode.
When storing a group of e-mail IDs, a list is a better fit than a set. Why? The e-mail
IDs are ordered by how you insert them. You can control this order. Thus, for
example, it has a record of the primary e-mail. A set will not work for this. However,
the primary advantage of a list is that you don't need fields, such as
email1
,
email2
,
or
email3
.
Dealing with lost usernames and
passwords
Now imagine that a user has lost his/her username, but the user remembers his/
her e-mail ID. You just keyed everything on the username, so without it we are lost.
You can read
all
the entries in the database in the attempt of finding this e-mail ID.
However, I don't have to convince you how bad this approach is.
So, I challenge you to design your approach. Most of my students, when presented
with this challenge in class, started changing the basic
user
table, preparing it for
additional queries. However, the right approach is more radical. Here's some advice
from one of the leading NoSQL architects, Patrick McFadin:
"Good question! (We are not alone in our struggle)."
I mention this topic in other venues, too. What do you do if you want to look up
by e-mail ID? This might be a good place for an index table, as follows:
create table email_index (
domain text,
username text,
user_id text,
PRIMARY KEY (domain, username)
);
