To Embed or Reference - MongoDB Applied Design Patterns - page 3

(“cell”) containing exactly one value. This requirement that each cell contains exactly one
value is, as we'll see later, a requirement that MongoDB does not impose, with the potential
for some nice performance gains. Back in our relational case, let's consider a phone book ap-
plication. Your initial data might be of the following form, shown in Table 1-1 .

Table 1-1. Phone book v1

id name phone_number zip_code

1 Rick 555-111-1234 30062

2 Mike 555-222-2345 30062

3 Jenny 555-333-3456 01209

This data is actually already in first normal form. Suppose, however, that we wished to allow
for multiple phone numbers for each contact, as in Table 1-2 .

Table 1-2. Phone book v2

id name phone_numbers zip_code

1 Rick 555-111-1234 30062

2 Mike 555-222-2345;555-212-2322 30062

3 Jenny 555-333-3456;555-334-3411 01209

Now we have a table that's no longer in first normal form. If we were to actually store data in
this form in a relational database, we would have to decide whether to store phone_numbers
as an unstructured BLOB of text or as separate columns (i.e., phone_number0 ,
phone_number1 ). Suppose we decided to store phone_numbers as a text column, as shown in
Table 1-2 . If we needed to implement something like caller ID, finding the name for a given
phone number, our SQL query would look something like the following:

SELECT SELECT name FROM FROM contacts WHERE WHERE phone_numbers LIKE LIKE '%555-222-2345%' ;