MongoDB for Developers with Python Transcripts
Chapter: Modeling and document design
Lecture: Do you have an integration database?
0:00 In order to answer this question about whether you have
0:02 an integration database or an application database,
0:04 let's do a quick compare and contrast,
0:07 especially in large enterprises, you'll see that they use databases
0:11 almost as a means of inter-application communication,
0:15 so maybe you have this huge relational database that lives in the center
0:18 with many, many constraints, many, many store procedures,
0:21 lots and lots of structures and rules, and so on,
0:25 why— well, because we have a bunch of different applications
0:28 and they all need to access this data,
0:30 maybe the one in the top left here it needs users
0:33 but so does the one on the right, and their idea of users is slightly different
0:36 so this user is not like a real simple thing, it's really quite complex
0:40 it's kind of the thing that will solve the user problem for all of these apps
0:43 and so on and so on, through the constraints and the way you use it.
0:47 This is a decent, well, it's typically a good role for relational databases,
0:51 you're better off with other architectural patterns anyway,
0:55 but relational databases are a good guarding against this kind of use case,
0:58 they have a fixed schema, they have lots of constraints and relationships
1:03 and they are very good at enforcing and kicking it back to the app
1:06 and go no, you got it wrong, you messed up the data.
1:08 So they can be like this strong rock in the middle.
1:11 The problem with rocks is they're not very adaptable,
1:14 they can't be massaged into new and interesting things;
1:18 a rock is a rock, and it's extremely hard to change.
1:21 So that's partly why some of these major enterprises
1:25 will have like weekends where they deploy a new version of an app,
1:28 like we're going to take it down and everybody's going to come in
1:30 and we're going to release it;
1:32 that is not a super place to be, it's also not a great use case
1:36 for document databases with their flexibility in schema design,
1:40 their less enforcement at the database level
1:43 and more enforcement inside the app,
1:45 because how is the app on the left going to help
1:47 enforce things for the app on the right, that's not great.
1:49 So, this is an integration database, and it's generally not a good use case
1:53 for document databases, if you're still using that
1:56 this sort of style of document databases, it means your queries will be more varied
1:59 and you probably need to model in a more relational style,
2:03 less embedded style, just as a rule of thumb.
2:06 So what's the opposite? Well, it might look like this,
2:09 we have all of our little apps again,
2:11 and instead of them all sharing a single massive database
2:13 you can maybe think of this is more like a micro service type of architecture;
2:17 each one of them is going to have their own database
2:20 and they're going to talk to it, and then when they need to exchange information
2:22 we'll do that through some sort of web api,
2:25 so they will exchange it through some kind of service broker way
2:29 they like negotiate and locate the other services, right,
2:32 maybe the one in the left is about orders,
2:34 the one on the right is about users and accounts.
2:37 So what that means though is each one of these little apps is much simpler,
2:41 it can have its own database with its own focused query patterns,
2:45 which is more focused, easier to understand,
2:48 and the application can enforce the structure and the integrity at its api level,
2:53 so this is a much better use case when you're sharing data with a document database.
2:58 And in fact, this sort of whole pattern here means
3:01 we don't have to make it NoSQL versus SQL choice,
3:03 maybe three out of these six are using MongoDB,
3:07 one is using a graph database and two are using MySQL,
3:10 it's up to the individual application to decide what the best way
3:13 and model basically with the best database and its underlying model is.
3:18 So when we have an application database like this
3:20 you are more likely to have slightly more embedded objects
3:24 because the query patterns are going to be simpler and more focused and more constraint.