MDB.LOCAL19 - Chicago: From SQL to NoSQL -- Changing Your Mindset

When you need to model data, is your first instinct to start breaking it down into rows and columns? Mine used to be too. When you want to develop apps in a modern, agile way, NoSQL databases can be the best option. Come to this talk to learn how to take advantage of all that NoSQL databases have to offer and discover the benefits of changing your mindset from the legacy, tabular way of modeling data. We’ll compare and contrast the terms and concepts in SQL databases and MongoDB, explain the benefits of using MongoDB compared to SQL databases, and walk through data modeling basics so you feel confident as you begin using MongoDB.

Transcript

1. #MDBlocal [Jumpstart] From SQL to NoSQL: Changing your Mindset @JoeKarlsson1 Joe Karlsson
2. Did you know that the two main bottlenecks for web app performance are: @JoeKarlsson1 Source: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 * Network speed * Database execution speed
3. We can only control one of these things @JoeKarlsson1 Source: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4
4. @JoeKarlsson1
5. { name: “Joe Karlsson”, company: “MongoDB”, pronouns: “He/They”, title: [ “Developer Advocate”, “Software Engineer” ], twitter: “@JoeKarlsson1”, website: “joekarlsson.com”, }
6. @JoeKarlsson1 MagicMirror^2 @JoeKarlsson1
7. @JoeKarlsson1 Moodlite @JoeKarlsson1
8. @JoeKarlsson1 Want to watch me make stuff? https://www.twitch.tv/joe_karlsson @JoeKarlsson1
9. Before we get started… @JoeKarlsson1
10. Thank you so much for coming! @JoeKarlsson1
11. Who’s this talk for? @JoeKarlsson1
12. @JoeKarlsson1
13. How’s this talk going to work? @JoeKarlsson1
14. Feel free to ask questions at anytime @JoeKarlsson1
15. Want to follow along? @JoeKarlsson1 http://bit.ly/FromSQLtoNoSQLChicago
16. Get the slides/ resources on my Twitter after the talk: @JoeKarlsson1 @JoeKarlsson1
17. Quick Audience Poll @JoeKarlsson1
18. @JoeKarlsson1
19. Agenda 1.Map terms & concepts from SQL to MongoDB 2.Discover the 4 humongous advantages of MongoDB 3.Change your mindset in 3 key ways @JoeKarlsson1
20. Agenda 1.Map terms & concepts from SQL to MongoDB 2.Discover the 4 humongous advantages of MongoDB 3.Change your mindset in 3 key ways @JoeKarlsson1 Row Column Table Database Index Join Join Left Outer Join Recursive Common Table Expressions View Transaction Document Field Collection Database Index Embedding Database References $lookup $graphLookup View Transaction
21. @JoeKarlsson1 MongoDB stores data in documents
22. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
23. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
24. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
25. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
26. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
27. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
28. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
29. @JoeKarlsson1 MongoDB stores data in documents { 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 } ] }
30. @JoeKarlsson1 Modeling data in MongoDB vs SQL { 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 } ] }
31. @JoeKarlsson1 Modeling data in MongoDB vs SQL { 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 first_name surname cell city location_x location_y 1 Paul Miller 447557505611 London 45.123 47.232 Users
32. @JoeKarlsson1 Modeling data in MongoDB vs SQL { 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 first_name surname cell city location_x location_y 1 Paul Miller 447557505611 London 45.123 47.232 Users
33. @JoeKarlsson1 Modeling data in MongoDB vs SQL { 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 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 447557505611 London 45.123 47.232 Users
34. @JoeKarlsson1 Modeling data in MongoDB vs SQL { 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 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 447557505611 London 45.123 47.232 Users
35. @JoeKarlsson1 Collections vs Tables { 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 } ] } { first_name: ”Joe", surname: ”Karlsson", cell: ”1235552222", city: ”Minneapolis”, profession: [”software engineer", ”developer advocate"], } { first_name: ”BMO", surname: ”Karlsson", city: ”Minneapolis", } Users Users ID first_name surname cell city location_ x location_y 1 Paul Miller 447557505611 London 45.123 47.232 2 Joe Karlsson 1235552222 Minneapolis NULL NULL 3 Sydney Schaefer NULL Minneapolis NULL NULL
36. @JoeKarlsson1 Collections vs Tables { 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 } ] } { first_name: ”Joe", surname: ”Karlsson", cell: ”1235552222", city: ”Minneapolis”, profession: [”software engineer", ”developer advocate"], } { first_name: ”BMO", surname: ”Karlsson", city: ”Minneapolis", } Users Users ID first_name surname cell city location_ x location_y 1 Paul Miller 447557505611 London 45.123 47.232 2 Joe Karlsson 1235552222 Minneapolis NULL NULL 3 BMO Karlsson NULL Minneapolis NULL NULL
37. @JoeKarlsson1 Collections vs Tables { 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 } ] } { first_name: ”Joe", surname: ”Karlsson", cell: ”1235552222", city: ”Minneapolis”, profession: [”software engineer", ”developer advocate"], } { first_name: ”BMO", surname: ”Karlsson", city: ”Minneapolis", } Users Users ID first_name surname cell city location_ x location_y 1 Paul Miller 447557505611 London 45.123 47.232 2 Joe Karlsson 1235552222 Minneapolis NULL NULL 3 BMO Karlsson NULL Minneapolis NULL NULL
38. Don’t panic! Use schema validation. Flexible schema
 database
39. Document Row(s) ID a ... 1 b ... 2 ... ... 3 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... { ...
 a: “b”
 ... }
40. Field ID a ... 1 b ... 2 c ... 3 ... ... { ...
 a: “b”
 ... } { ...
 a: “c”
 ... } Column
41. Table Collection { ... } ... ... ... ... ... ... ... ... ... ... ... ... { ... } { ... }
42. @JoeKarlsson1 Time for a terrible joke
43. @JoeKarlsson1 So a DBA walks
 into a NoSQL bar… But immediately leaves because they couldn’t find table.
44. @JoeKarlsson1
45. Database Database ... ... ... ... ... ... ... ... ... ... ... ... { ... } { ... } { ... } { ... } { ... } { ... } { ... } ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
46. Index Index { ... } { ... } { ... } { ... } ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
47. View View { ... } ... ... ... ... ... ... ... ... ... ... ... ... { ... } { ... }
48. Embedding { ...
 a: “b”,
 ... c: {
 d: “e”
 ...
 },
 ... } ID a ... 1 b ... 2 ... ... 3 ... ... ... d ... 1 e ... ... ... ... Join
49. Multi-Record ACID Transaction Multi-Document ACID Transaction { ... } { ... } { ... } { ... } { ... } { ... } { ... } ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
50. @JoeKarlsson1 The journey from SQL to MongoDB
51. @JoeKarlsson1 Row Column Table Database Index Join Join Left Outer Join Recursive Common Table Expressions View Transaction Document Field Collection Database Index Embedding Database References $lookup $graphLookup View Transaction The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB
52. Agenda 1.Map terms & concepts from SQL to MongoDB 2.Discover the 4 humongous advantages of MongoDB 3.Change your mindset in 3 key ways @JoeKarlsson1 1.Program faster 2.Pivot easier 3.Query faster 4.Scale Cheaper
53. @JoeKarlsson1 Program faster! Update Your Profile Documents map to data structures in most popular languages.
54. @JoeKarlsson1 Program faster! { first_name: "Paul", surname: "Miller", cell: "447557505611", city: "London", location: [45.123,47.232], profession: ["banking", "finance", "trader"], } 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
55. import pymongo
 from pymongo import MongoClient # CONNECT TO THE DB client = MongoClient() client =
 pymongo.MongoClient("mongodb+srv://
 username:password@cluster0nsdia.
 mongodb.net/test?retryWrites=true") db = client.fabapp 
 # THE ID OF THE USER WHOSE PROFILE WE WILL BE RETRIEVING AND UPDATING userId = 1 Program faster! import mysql.connector 
 # CONNECT TO THE DB mydb = mysql.connector.connect(
 host="localhost",
 user=”username",
 passwd=”password",
 database=”fabapp”
 ) mycursor = mydb.cursor() 
 # THE ID OF THE USER WHOSE PROFILE WE WILL BE RETRIEVING AND UPDATING userId = 1
56. # GET THE USER'S PROFILE INFORMATION ### Pull the info from the Users table & put it in the user dictionary sql = "Select * FROM Users WHERE Users.ID=%s”
 values = (userId,)
 mycursor.execute(sql, values)
 result = mycursor.fetchone() user = {
 "first_name": result[1],
 "surname": result[2],
 "cell": result[3],
 "city": result[4],
 "location_x": result[5],
 "location_y": result[6]
 } # GET THE USER'S PROFILE INFORMATION ## We can pull all of the info from the same document since we used embedding user = db['Users'].find_one({"_id": userId}) Program faster! ### Pull the info from the Professions table & put it in the user dictionary sql = "Select * FROM Professions WHERE
 Professions.user_id=%s”
 values = (userId,)
 mycursor.execute(sql, values)
 results = mycursor.fetchall() professions = []
 for result in results:
 professions.append(result[2])
 user["professions"] = professions
57. # UPDATE THE USER DICTIONARY BASED ON USER INPUT IN THE APP ### We'll update the user dictionary manually for simplicity user = {
 "first_name": "NewFirst",
 "surname": "NewSurname",
 "cell": "123-456-7890",
 "city": "NewCity",
 "location": [40.762, -73.979],
 "professions": [”Manager", "Engineer"]
 } Program faster! # UPDATE THE USER DICTIONARY BASED ON USER INPUT IN THE APP ### We'll update the user dictionary manually for simplicity user = {
 "first_name": "NewFirst",
 "surname": "NewSurname",
 "cell": "123-456-7890",
 "city": "NewCity",
 "location_x": 40.762, 
 "location_y": 73.979,
 "professions": [”Manager", "Engineer"]
 }
58. # UPDATE THE USER'S PROFILE IN THE DATABASE ### First update what is stored in the Users table sql = "UPDATE Users SET first_name=%s, surname=%s, cell=%s, city=%s, location_x=%s, location_y=%s WHERE (ID=%s)"
 values = (
 user["first_name"], 
 user["surname"], 
 user["cell"], 
 user["city"], 
 user["location_x"], 
 user["location_y"], 
 userId)
 mycursor.execute(sql, values) mydb.commit() # UPDATE THE USER'S PROFILE IN THE DATABASE ### Since the user's data is stored in a single document, we only have to make one update result = db['Users'].update_one(
 {"_id": userId}, {"$set": user}) 
 Program faster! ### Delete existing records in Professions table and add new ones sql = "DELETE FROM Professions WHERE user_id=%s”
 values = (userId,)
 mycursor.execute(sql, values)
 mydb.commit() if(len(user["professions"]) > 0):
 sql = "INSERT INTO Professions 
 (user_id,profession) VALUES (%s, %s)”
 values = []
 for profession in user["professions"]:
 values.append((userId, profession))
 mycursor.executemany(sql,values)
 mydb.commit()
59. 30 lines of code Program faster! 73 lines of code
60. @JoeKarlsson1 Pivot easier! Easily change the shape of your data as your app evolves. SQL MongoDB {
 a: “b”,
 c: “one”,
 e: “f” } {
 a: “b”,
 c: 1,
 new: “no biggee” } ALTER TABLE `mydb`.`letters_table` DROP COLUMN `e`, ADD COLUMN `New` VARCHAR(45) NULL AFTER `C`, CHANGE COLUMN `C` `C` INT NULL DEFAULT NULL ;
61. @JoeKarlsson1 Query faster! Stop doing expensive joins to get your data. SQL MongoDB ID a ... 1 b ... 2 ... ... 3 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... { ...
 a: “b”,
 ... c: {
 d: “e”
 ...
 },
 ... }
62. @JoeKarlsson1 Scale cheaper! As the size of your server grows, scale horizontally.
63. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB
64. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 1. Program faster # UPDATE THE USER'S PROFILE IN THE DATABASE ### First update what is stored in the Users table sql = "UPDATE Users SET first_name=%s, surname=%s, cell=%s, city=%s, location_x=%s, location_y=%s WHERE (ID=%s)"
 values = (
 user["first_name"], 
 user["surname"], 
 user["cell"], 
 user["city"], 
 user["location_x"], 
 user["location_y"], 
 userId)
 mycursor.execute(sql, values) mydb.commit() # UPDATE THE USER'S PROFILE IN THE DATABASE ### Since the user's data is stored in a single document, we only have to make one update result = db['Users'].update_one(
 {"_id": userId}, {"$set": user}) 

65. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 2. Scale cheaper 1. Program faster
66. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 3. Query faster 2. Scale cheaper 1. Program faster
67. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 4. Pivot easier 3. Query faster 2. Scale cheaper 1. Program faster
68. Agenda 1.Map terms & concepts from SQL to MongoDB 2.Discover the 4 humongous advantages of MongoDB 3.Change your mindset in 3 key ways @JoeKarlsson1 1.Not all documents in a collection need to have the same fields. 2.Data that is accessed together should be stored together. 3.Stop using transactions regularly.
69. @JoeKarlsson1 Not all documents in a collection need to have the same fields.
70. @JoeKarlsson1 Not all documents in a collection need to have the same fields. The Polymorphic Pattern { 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 } ] } { first_name: ”Joe", surname: ”Karlsson", cell: ”1235552222", city: ”Minneapolis”, profession: [”software engineer", ”developer advocate"], } { first_name: ”BMO", surname: ”Karlsson", city: ”Minneapolis", }
71. @JoeKarlsson1 Not all documents in a collection need to have the same fields. The Outlier Pattern { _id: ”JoeKarlsson1", displayName: ”JoeKarlsson1”, 
 numFollowers: 2095 followers: [
 “jessicaewest”,
 “wesley83”, 
 “GraceFr”
 ... ] } { _id: ”KimKardashian", displayName: ”Kim Kardashian West", 
 numFollowers: 62104245 followers: [
 “c_hotaling”,
 “IAmJerdog”, 
 “ChloeCondon”
 ... ], has_extras: true { _id: ”KimKardashian_1", twitter_id: “KimKardashian”,
 is_overflow: true, followers: [
 “StephenAtHome”,
 “TheEllenShow”, 
 “hulu”
 ... ] }
72. @JoeKarlsson1 Data that is accessed together should be stored together.
73. @JoeKarlsson1 Storage vs Developer Costs 0 25000 50000 75000 100000 1985 2017 Storage Cost per GB Developer Salary Data that is accessed together should be stored together.
74. @JoeKarlsson1 Data that is accessed together should be stored together. Don’t normalize your data for the sake of normalizing it. {
 a: “b”, c: {
 d: “e”
 ...
 }, f: [“g”, “h”, “i”], j: [ 
 { k: “l” }, 
 { m: “n” } ] }
75. @JoeKarlsson1 Stop using transactions regularly. Relying on transactions is a bad design smell. { ... } { ... } { ... } { ... } { ... } { ... } { ... }
76. @JoeKarlsson1 Stop using transactions regularly. Relying on transactions is a bad design smell. { ... } { ... } { ... } { ... } { ... } { ... } { ... }
77. @JoeKarlsson1 The journey from SQL to MongoDB
78. @JoeKarlsson1 Row Column Table Database Index Join Join Left Outer Join Recursive Common Table Expressions View Transaction Document Field Collection Database Index Embedding Database References $lookup $graphLookup View Transaction The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB
79. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB
80. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 1. Program faster # UPDATE THE USER'S PROFILE IN THE DATABASE ### First update what is stored in the Users table sql = "UPDATE Users SET first_name=%s, surname=%s, cell=%s, city=%s, location_x=%s, location_y=%s WHERE (ID=%s)"
 values = (
 user["first_name"], 
 user["surname"], 
 user["cell"], 
 user["city"], 
 user["location_x"], 
 user["location_y"], 
 userId)
 mycursor.execute(sql, values) mydb.commit() # UPDATE THE USER'S PROFILE IN THE DATABASE ### Since the user's data is stored in a single document, we only have to make one update result = db['Users'].update_one(
 {"_id": userId}, {"$set": user}) 

81. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 2. Scale cheaper 1. Program faster
82. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 3. Query faster 2. Scale cheaper 1. Program faster
83. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 4. Pivot easier 3. Query faster 2. Scale cheaper 1. Program faster
84. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 3) Change your mindset in 3 key ways
85. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 3) Change your mindset in 3 key ways 1. Not all documents in a collection need to have the same fields. { 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 } ] } { first_name: ”Joe", surname: ”Karlsson", cell: ”1235552222", city: ”Minneapolis”, profession: [”software engineer", ”developer advocate"], } { first_name: ”BMO", surname: ”Karlsson", city: ”Minneapolis", }
86. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 3) Change your mindset in 3 key ways 1. Not all documents in a collection need to have the same fields. 2. Data that is accessed together should be stored together. {
 a: “b”, c: {
 d: “e”
 ...
 }, f: [“g”, “h”, “i”], j: [ 
 { k: “l” }, 
 { m: “n” } ] }
87. @JoeKarlsson1 The journey from SQL to MongoDB 1) Map terms & concepts from SQL to MongoDB 2) Discover the 4 humongous advantages of MongoDB 3) Change your mindset in 3 key ways 1. Not all documents in a collection need to have the same fields. 2. Data that is accessed together should be stored together. 3. Stop using transactions regularly. { ... } { ... } { ... } { ... } { ... } { ... } { ... }
88. What’s next? @JoeKarlsson1
89. MongoDB Community • MongoDB University: • university.mongodb.com
 • Recommended Course: • M001: MongoDB Basics @JoeKarlsson1
90. http://bit.ly/MongoDBChicago2019
91. Recommended Sessions: • A MongoDB Journey: Moving from a Relational Database to MongoDB Atlas [Northwestern Mutual] • 9:30am - 10:15am: Ballroom 2 • Tutorial: Practical Data Modeling for MongoDB • 12:30pm - 2:15pm: Ballroom 3 • Tips and Tricks++ for Querying and Indexing MongoDB [MongoDB] • 2:35pm - 3:20pm: Ballroom 5 @JoeKarlsson1
92. @JoeKarlsson1 Thank you!
93. { name: “Joe Karlsson”, company: “MongoDB”, title: [ “Developer Advocate”, “Software Engineer” ], twitter: “@JoeKarlsson1”, website: “joekarlsson.com”, }
94. #MDBlocal [Jumpstart] From SQL to NoSQL - Changing your Mindset https://www.surveymonkey.com/r/6NS88JY Every session you rate enters you into a drawing for a $250 Visa gift card, sponsored by
95. Additional Resources •http://bit.ly/MongoDBChicago2019 •$200 in free Atlas credits • Advanced Schema Design Patterns (webinar) • Building with Patterns: A Summary (blog series) • M320: Data Modeling (MongoDB University Course) @JoeKarlsson1
96. Additional Resources @JoeKarlsson1 • The MongoDB Docs • JSON Schema Validation – Locking down your model the smart way • JSON Schema Validation - Checking Your Arrays • M121: The MongoDB Aggregation Framework