Slide 1
Slide 1 text
MongoDB Schema
Design Best Practices
Joe Karlsson | Developer Advocate | @JoeKarlsson1
Slide 2
Slide 2 text
@JoeKarlsson1
Why is schema
design so important?
Critical for improving the
performance and scalability
of your database
Slide 3
Slide 3 text
{
name: “Joe Karlsson”,
company: “MongoDB”,
title: [
“Developer Advocate”,
“Software Engineer”
],
}
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”,
opinions: “my own”,
links: “bit.ly/IoTKittyBox”
Slide 4
Slide 4 text
Agenda
@JoeKarlsson1
Relational vs. MongoDB
Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
Slide 5
Slide 5 text
Agenda
@JoeKarlsson1
Relational vs. MongoDB
Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
Slide 6
Slide 6 text
Relational vs. MongoDB
Schema Design Approaches
@JoeKarlsson1
Slide 7
Slide 7 text
Slide for your video:
Add your video. Depending on the resolution
you want to leave a black border.
Most Devs
Slide 8
Slide 8 text
Slide for your video:
Add your video. Depending on the resolution
you want to leave a black border.
Slide 9
Slide 9 text
@JoeKarlsson1
Relational
Schema Design
Slide 10
Slide 10 text
@JoeKarlsson1
Model data independent of queries
Slide 11
Slide 11 text
@JoeKarlsson1
What
data do
I have?
Slide 12
Slide 12 text
@JoeKarlsson1
Prescribed approaches
Normalize in the 3rd form
Slide 13
Slide 13 text
@JoeKarlsson1
tl;dr:
Don’t duplicate data
Slide 14
Slide 14 text
@JoeKarlsson1
ID user_id model year
20 1 Bentley 1973
21 1 Rolls Royce 1965
Cars
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
Professions
ID first_name surname cell city location_x location_y
1 Paul Miller 44755750561
1
London 45.123 47.232
Users
Slide 15
Slide 15 text
@JoeKarlsson1
MongoDB
Schema Design
Slide 16
Slide 16 text
No Rules
No Process
No Algorithm
MongoDB
Schema
Design
Slide 17
Slide 17 text
Slide for your video:
Add your video. Depending on the resolution
you want to leave a black border.
Slide 18
Slide 18 text
@JoeKarlsson1
Design a schema that will work well for a given application
Slide 19
Slide 19 text
Reasonable amount of
hardware
How to store the data
MongoDB Schema Design
Query Performance
Slide 20
Slide 20 text
@JoeKarlsson1
ID user_id model year
20 1 Bentley 1973
21 1 Rolls Royce 1965
Cars
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
Professions
ID first_name surname cell city location_x location_y
1 Paul Miller 44755750561
1
London 45.123 47.232
Users
Slide 21
Slide 21 text
@JoeKarlsson1
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
}
MongoDB
Relational
ID first_name surname cell city location_x location_y
1 Paul Miller 447557505611 London 45.123 47.232
Users
Slide 22
Slide 22 text
@JoeKarlsson1
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
}
profession: ["banking", "finance", "trader"],
MongoDB
Relational
ID first_name surname cell city location_x location_y
1 Paul Miller 447557505611 London 45.123 47.232
Users
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
Professions
Slide 23
Slide 23 text
@JoeKarlsson1
MongoDB
Relational
ID first_name surname cell city location_x location_y
1 Paul Miller 447557505611 London 45.123 47.232
Users
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
}
profession: ["banking", "finance", "trader"],
cars: [
{
model: "Bentley",
year: 1973
},
{
model: "Rolls Royce",
year: 1965
}
]
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
Professions
ID user_id model year
20 1 Bentley 1973
21 1 Rolls Royce 1965
Cars
Slide 24
Slide 24 text
Relational vs. MongoDB Schema Design Approaches
Slide 25
Slide 25 text
Relational vs. MongoDB Schema Design Approaches
Relational Schema Design
Slide 26
Slide 26 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Relational Schema Design
Slide 27
Slide 27 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
ID user_id model year
20 1 Bentley 1973
21 1 Rolls Royce 1965
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
ID first_name surname cell city location_x location_y
1 Paul Miller 447557505611 London 45.123 47.232
Slide 28
Slide 28 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
Slide 29
Slide 29 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
No rules, no process, no algorithm
Slide 30
Slide 30 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
No rules, no process, no algorithm
Considerations:
How to store the data
Query Performance
Slide 31
Slide 31 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
No rules, no process, no algorithm
Considerations:
How to store the data
Query Performance
Design a schema that works for your application
Slide 32
Slide 32 text
Agenda
@JoeKarlsson1
Relational vs. MongoDB
Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
Slide 33
Slide 33 text
@JoeKarlsson1
Embedding
vs. Referencing
Slide 34
Slide 34 text
Embedding
{
_id : ObjectId('AAA'),
name: 'Kate Monster',
ssn: '123-456-7890',
addresses: [
{
street: '123 Sesame St’,
city: 'Anytown', cc: ‘USA'
},
{
street: '123 Avenue Q',
city: 'New York',
cc: ‘USA'
}
]
}
Slide 35
Slide 35 text
Embedding
{
...
a: “b”,
...
c: {
d: “e”
...
},
...
}
ID a ...
1 b ...
2 ... ...
3 ... ...
... d ...
1 e ...
... ... ...
Join
Slide 36
Slide 36 text
Con
Pro
Embedding
Retrieve all data with a
single query
Avoids expense JOINs or $lookup
Update all data with a single
atomic operation
Large docs === more overhead
16 MB Document size limit
Slide 37
Slide 37 text
Referencing
{
_id : ObjectID('AAAA'),
partno : '123-aff-456',
name : '#4 grommet',
qty: 94,
cost: 0.94,
price: 3.99
}
{
name : 'left-handed smoke shifter',
manufacturer : 'Acme Corp',
catalog_number: 1234,
parts : [
ObjectID('AAAA'),
ObjectID('BBBB'),
]
}
{
_id : ObjectID('BBB'),
partno : '425-EFF-123',
name : '#8 Frombet',
qty: 13,
cost: 0.34,
price: 7.99
}
Slide 38
Slide 38 text
Con
Pro
Referencing
Smaller documents
Less likely to reach 16 MB limit
No duplication of data
Two queries or $lookup
required to retrieve all data
Infrequently accessed data
not accessed on every query
Slide 39
Slide 39 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Slide 40
Slide 40 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
{
_id : ObjectId('AAA'),
name: 'Kate Monster',
ssn: '123-456-7890',
addresses: [
{
street: '123 Sesame St’,
city: 'Anytown', cc: ‘USA'
},
{
street: '123 Avenue Q',
city: 'New York',
cc: ‘USA'
}
]
}
Slide 41
Slide 41 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
{
...
a: “b”,
...
c: {
d: “e”
...
},
...
}
ID a ...
1 b ...
2 ... ...
3 ... ...
... d ...
1 e ...
... ... ...
Slide 42
Slide 42 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
Retrieve all data with a single query
Update all data with a single atomic operation
Avoids expense JOINs or $lookup
Slide 43
Slide 43 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
Retrieve all data with a single query
Update all data with a single atomic operation
Large docs === more overhead
16 MB Document size limit
Avoids expense JOINs or $lookup
Slide 44
Slide 44 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding
Referencing:
{
_id : ObjectID('AAAA'),
partno : '123-aff-456',
name : '#4 grommet',
qty: 94,
cost: 0.94,
price: 3.99
}
{
name : 'left-handed smoke shifter',
manufacturer : 'Acme Corp',
catalog_number: 1234,
parts : [
ObjectID('AAAA'),
ObjectID('BBBB'),
ObjectID('CCCC')
]
}
{
_id : ObjectID('BBB'),
partno : '425-EFF-123',
name : '#8 Frombet',
qty: 13,
cost: 0.34,
price: 7.99
}
Slide 45
Slide 45 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding
Referencing:
Smaller documents
Less likely to reach 16 MB limit
No duplication of data
Infrequently accessed data not accessed on every query
Slide 46
Slide 46 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding
Referencing:
Smaller documents
Less likely to reach 16 MB limit
No duplication of data
Two queries or $lookup required to retrieve all data
Infrequently accessed data not accessed on every query
Slide 47
Slide 47 text
Agenda
@JoeKarlsson1
Relational vs. MongoDB
Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
Slide 48
Slide 48 text
@JoeKarlsson1
Types of
Relationships
Slide 49
Slide 49 text
@JoeKarlsson1
One to One
Slide 50
Slide 50 text
@JoeKarlsson1
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”
}
One to One Use Key-Value pairs
User:
Slide 51
Slide 51 text
@JoeKarlsson1
One to Few
Slide 52
Slide 52 text
@JoeKarlsson1
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”,
addresses: [
{ street: “123 Sesame St", city: “Anytown”, cc: “USA" },
{ street: "123 Avenue Q", city: “New York”, cc: ”USA” }
]
}
One to Few
Prefer embedding
Slide 53
Slide 53 text
Rule 1:
Favor embedding unless
there is a compelling
reason not to.
Slide 54
Slide 54 text
Rule 2:
Needing to access an
object on its own is a
compelling reason not to
embed it.
Slide 55
Slide 55 text
@JoeKarlsson1
One to Many
Slide 56
Slide 56 text
@JoeKarlsson1
{
_id: ObjectId(“123"),
name: “left-handed smoke shifter”,
manufacturer: “Acme Corp”,
catalog_number: 1234,
parts: [
ObjectId(“AAA”),
ObjectId(“BBB”),
ObjectId(“CCC”),
]
}
One to Many Prefer referencing
Products:
{
_id: ObjectId(“AAA"),
partno: “123-ABC-456”,
name: “#4 grommet”,
qty: 94,
cost: 0.54,
price: 2.99,
}
Parts:
Slide 57
Slide 57 text
Rule 3:
Avoid JOINs and $lookups if
they can be, but don’t be afraid
if they can provide a better
schema design.
Slide 58
Slide 58 text
@JoeKarlsson1
One to Squillions
Slide 59
Slide 59 text
@JoeKarlsson1
{
_id: ObjectId(“AAA"),
name: “goofy.example.com”,
ipaddr: “127.66.66.66”,
}
One to Squillions Prefer referencing
Hosts:
{
_id: ObjectId(“123”),
time: ISODate(“2014-03-28T09:42:41.382Z”),
message: “The CPU is on fire!!!”,
host: ObjectId(“AAA"),
},
Log Message:
{
_id: ObjectId(“456”),
time: ISODate(“2014-03-28T09:42:41.382Z”),
message: “Drive is hosed”,
host: ObjectId(“AAA"),
}
Slide 60
Slide 60 text
Rule 4:
Arrays should not
grow without bound.
Slide 61
Slide 61 text
@JoeKarlsson1
Many to Many
Slide 62
Slide 62 text
@JoeKarlsson1
{
_id: ObjectId(“AAF1"),
name: “Joe Karlsson”,
tasks: [
ObjectId(“ADF9”),
ObjectId(“AE02”),
ObjectId(“ZDF2”),
]
}
Many to Many Prefer referencing
Person:
{
_id: ObjectId(“ADF9”),
description: “Learn MongoDB”,
due_date: ISODate(“2014-03-28T09:42:41.382Z”),
owner: ObjectId(“AAF1”),
},
Tasks:
{
_id: ObjectId(“AE02”),
description: “Write lesson plan”,
due_date: ISODate(“2014-03-28T09:42:41.382Z”),
owner: ObjectId(“AAF1”),
},
Slide 63
Slide 63 text
Rule 5:
How you model your data
depends – entirely – on your
particular application’s data
access patterns.
Slide 64
Slide 64 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
Slide 65
Slide 65 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”
}
Slide 66
Slide 66 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
website: “joekarlsson.com”,
addresses: [
{ street: “123 Sesame St", city: “Anytown”, cc: “USA" },
{ street: "123 Avenue Q", city: “New York”, cc: ”USA” }
]
}
Slide 67
Slide 67 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
One to Many: Prefer Referencing
{
_id: ObjectId(“123"),
name: “left-handed smoke shifter”,
manufacturer: “Acme Corp”,
catalog_number: 1234,
parts: [
ObjectId(“AAA”),
ObjectId(“BBB”),
ObjectId(“CCC”),
]
}
{
_id: ObjectId(“AAA"),
partno: “123-ABC-456”,
name: “#4 grommet”,
qty: 94,
cost: 0.54,
price: 2.99,
}
Slide 68
Slide 68 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
One to Many: Prefer Referencing
One to Squillions: Prefer Referencing
{
_id: ObjectId(“AAA"),
name: “goofy.example.com”,
ipaddr: “127.66.66.66”,
}
{
_id: ObjectId(“123”),
time: ISODate(“2014-03-28T09:42:41.382Z”),
message: “The CPU is on fire!!!”,
host: ObjectId(“AAA"),
},
{
_id: ObjectId(“456”),
time: ISODate(“2014-03-28T09:42:41.382Z”),
message: “Drive is hosed”,
host: ObjectId(“AAA"),
}
Slide 69
Slide 69 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
One to Many: Prefer Referencing
One to Squillions: Prefer Referencing
Many to Many: Prefer Referencing
{
_id: ObjectId(“AAF1"),
name: “Joe Karlsson”,
tasks: [
ObjectId(“ADF9”),
ObjectId(“AE02”),
ObjectId(“ZDF2”),
]
}
{
_id: ObjectId(“ADF9”),
description: “Learn MongoDB”,
due_date: ISODate(“2014-03-28T09:42:41.38
owner: ObjectId(“AAF1”),
},
{
_id: ObjectId(“AE02”),
description: “Write lesson plan”,
due_date: ISODate(“2014-03-28T09:42:41.382Z”),
owner: ObjectId(“AAF1”),
},
Slide 70
Slide 70 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Slide 71
Slide 71 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Slide 72
Slide 72 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Avoid JOINs and $lookups if they can be avoided
Slide 73
Slide 73 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Avoid JOINs and $lookups if they can be avoided
Arrays should not grow without bound
Slide 74
Slide 74 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Avoid JOINs and $lookups if they can be avoided
Arrays should not grow without bound
How you model your data depends – entirely – on your
particular application’s data access patterns
Slide 75
Slide 75 text
@JoeKarlsson1
Hybrid Approaches
Advanced
Slide 76
Slide 76 text
Not all documents in a collection
need to have the same fields.
Slide 77
Slide 77 text
@JoeKarlsson1
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”
}
Polymorphic Pattern
{
_id: ObjectId(“BBB"),
name: “BMO”,
city: “Minneapolis”
}
Slide 78
Slide 78 text
Imagine you are
building a Twitter like
social media site…
Slide 79
Slide 79 text
@JoeKarlsson1
{
_id: “JoeKarlsson1”,
disaplyName: “Joe Karlsson”,
numFollowers: “11563”,
followers: [
“mongodb”,
“jdrumgoole”,
“Lauren_Schaefer”,
…
]
}
A Normal User
Slide 80
Slide 80 text
But what if
Kim Kardashian
joined your site?
Slide 81
Slide 81 text
No content
Slide 82
Slide 82 text
@JoeKarlsson1
Outlier Pattern
{
_id: “KimKardashian”,
disply_name: “Kim Kardashian West”,
num_followers: “64500485”,
followers: [
“KrysJenner”,
“Caitlyn_Jenner”,
“chrissyteigen”,
…
],
has_extras: true
}
{
_id: “KimKardashian_1”,
twitter_id: “KimKardashian”,
is_overflow: “True”,
followers: [
“kanyewest”,
“TheEllenShow”,
“Oprah”,
…
],
has_extras: true
}
Slide 83
Slide 83 text
But wait, there are a
ton of other patterns in
your tool belt
Slide 84
Slide 84 text
@JoeKarlsson1
https://www.mongodb.com/blog/post/building-with-patterns-a-summary
Slide 85
Slide 85 text
Relational vs. MongoDB Schema Design Approaches
Slide 86
Slide 86 text
Relational vs. MongoDB Schema Design Approaches
Relational Schema Design
Slide 87
Slide 87 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Relational Schema Design
Slide 88
Slide 88 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
ID user_id model year
20 1 Bentley 1973
21 1 Rolls Royce 1965
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
ID first_name surname cell city location_x location_y
1 Paul Miller 447557505611 London 45.123 47.232
Slide 89
Slide 89 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
Slide 90
Slide 90 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
No rules, no process, no algorithm
Slide 91
Slide 91 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
No rules, no process, no algorithm
Considerations:
How to store the data
Query Performance
Slide 92
Slide 92 text
Relational vs. MongoDB Schema Design Approaches
Model data independent of queries
Normalize in the 3rd form
Relational Schema Design
MongoDB Schema Design
No rules, no process, no algorithm
Considerations:
How to store the data
Query Performance
Design a schema that works for your application
Slide 93
Slide 93 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Slide 94
Slide 94 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
{
_id : ObjectId('AAA'),
name: 'Kate Monster',
ssn: '123-456-7890',
addresses: [
{
street: '123 Sesame St’,
city: 'Anytown', cc: ‘USA'
},
{
street: '123 Avenue Q',
city: 'New York',
cc: ‘USA'
}
]
}
Slide 95
Slide 95 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
{
...
a: “b”,
...
c: {
d: “e”
...
},
...
}
ID a ...
1 b ...
2 ... ...
3 ... ...
... d ...
1 e ...
... ... ...
Slide 96
Slide 96 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
Retrieve all data with a single query
Update all data with a single atomic operation
Avoids expense JOINs or $lookup
Slide 97
Slide 97 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding:
Retrieve all data with a single query
Update all data with a single atomic operation
Large docs === more overhead
16 MB Document size limit
Avoids expense JOINs or $lookup
Slide 98
Slide 98 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding
Referencing:
{
_id : ObjectID('AAAA'),
partno : '123-aff-456',
name : '#4 grommet',
qty: 94,
cost: 0.94,
price: 3.99
}
{
name : 'left-handed smoke shifter',
manufacturer : 'Acme Corp',
catalog_number: 1234,
parts : [
ObjectID('AAAA'),
ObjectID('BBBB'),
ObjectID('CCCC')
]
}
{
_id : ObjectID('BBB'),
partno : '425-EFF-123',
name : '#8 Frombet',
qty: 13,
cost: 0.34,
price: 7.99
}
Slide 99
Slide 99 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding
Referencing:
Smaller documents
Less likely to reach 16 MB limit
No duplication of data
Infrequently accessed data not accessed on every query
Slide 100
Slide 100 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Embedding
Referencing:
Smaller documents
Less likely to reach 16 MB limit
No duplication of data
Two queries or $lookup required to retrieve all data
Infrequently accessed data not accessed on every query
Slide 101
Slide 101 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
Slide 102
Slide 102 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”
}
Slide 103
Slide 103 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
{
_id: ObjectId(“AAA"),
name: “Joe Karlsson”,
company: “MongoDB”,
twitter: “@JoeKarlsson1”,
website: “joekarlsson.com”,
addresses: [
{ street: “123 Sesame St", city: “Anytown”, cc: “USA" },
{ street: "123 Avenue Q", city: “New York”, cc: ”USA” }
]
}
Slide 104
Slide 104 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
One to Many: Prefer Referencing
{
_id: ObjectId(“123"),
name: “left-handed smoke shifter”,
manufacturer: “Acme Corp”,
catalog_number: 1234,
parts: [
ObjectId(“AAA”),
ObjectId(“BBB”),
ObjectId(“CCC”),
]
}
{
_id: ObjectId(“AAA"),
partno: “123-ABC-456”,
name: “#4 grommet”,
qty: 94,
cost: 0.54,
price: 2.99,
}
Slide 105
Slide 105 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
One to Many: Prefer Referencing
One to Squillions: Prefer Referencing
{
_id: ObjectId(“AAA"),
name: “goofy.example.com”,
ipaddr: “127.66.66.66”,
}
{
_id: ObjectId(“123”),
time: ISODate(“2014-03-28T09:42:41.382Z”),
message: “The CPU is on fire!!!”,
host: ObjectId(“AAA"),
},
{
_id: ObjectId(“456”),
time: ISODate(“2014-03-28T09:42:41.382Z”),
message: “Drive is hosed”,
host: ObjectId(“AAA"),
}
Slide 106
Slide 106 text
Relational vs. MongoDB Schema Design Approaches
Embedding vs. Referencing
Types of Relationships
One to One: Use Key-Value pairs
One to Few: Prefer embedding
One to Many: Prefer Referencing
One to Squillions: Prefer Referencing
Many to Many: Prefer Referencing
{
_id: ObjectId(“AAF1"),
name: “Joe Karlsson”,
tasks: [
ObjectId(“ADF9”),
ObjectId(“AE02”),
ObjectId(“ZDF2”),
]
}
{
_id: ObjectId(“ADF9”),
description: “Learn MongoDB”,
due_date: ISODate(“2014-03-28T09:42:41.38
owner: ObjectId(“AAF1”),
},
{
_id: ObjectId(“AE02”),
description: “Write lesson plan”,
due_date: ISODate(“2014-03-28T09:42:41.382Z”),
owner: ObjectId(“AAF1”),
},
Slide 107
Slide 107 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Slide 108
Slide 108 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Slide 109
Slide 109 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Avoid JOINs and $lookups if they can be avoided
Slide 110
Slide 110 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Avoid JOINs and $lookups if they can be avoided
Arrays should not grow without bound
Slide 111
Slide 111 text
MongoDB Schema Design Rules
Favor embedding unless there is a compelling reason not to
Needing to access an object on its own is a compelling
reason not to embed it
Avoid JOINs and $lookups if they can be avoided
Arrays should not grow without bound
How you model your data depends – entirely – on your
particular application’s data access patterns
Slide 112
Slide 112 text
@JoeKarlsson1
Questions?
Slide 113
Slide 113 text
@JoeKarlsson1
What’s Next?
Slide 114
Slide 114 text
@JoeKarlsson1
MongoDB
Community
university.mongodb.com
Recommended Course:
M320: Data Modeling
Slide 115
Slide 115 text
http://bit.ly/fromSQLToNoSQL
Slide 116
Slide 116 text
@JoeKarlsson1
Want $100 in FREE MongoDB Atlas
credits?
Use code JoeK100
http://bit.ly/FreeAtlasCredits
Slide 117
Slide 117 text
@JoeKarlsson1
Additional
Resources
Modeling: https://university.mongodb.com/
courses/M320/about
6 Rules of Thumb for MongoDB Schema Design:
Part 1: https://www.mongodb.com/blog/post/6-
rules-of-thumb-for-mongodb-schema-design-
part-1
Data Model Design: https://docs.mongodb.com/
manual/core/data-model-design/
Data Model Examples and Patterns: https://
docs.mongodb.com/manual/applications/data-
models/
Building with Patterns: A Summary: https://
www.mongodb.com/blog/post/building-with-
patterns-a-summary
Slide 118
Slide 118 text
{
name: “Joe Karlsson”,
company: “MongoDB”,
title: [
“Developer Advocate”,
“Software Engineer”
],
}
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”,
opinions: “my own”,
links: “bit.ly/IoTKittyBox”
Slide 119
Slide 119 text
@JoeKarlsson1
Thank you!
Slide 120
Slide 120 text
{
name: “Joe Karlsson”,
company: “MongoDB”,
title: [
“Developer Advocate”,
“Software Engineer”
],
}
twitter: “@JoeKarlsson1”,
twitch: “joe_karlsson”,
tiktok: “joekarlsson”,
website: “joekarlsson.com”,
opinions: “my own”,
links: “bit.ly/IoTKittyBox”
Slide 121
Slide 121 text
@JoeKarlsson1