|
1 | 1 | ## Principles of setting up your schema
|
2 | 2 |
|
3 | 3 | Poorly designed databases can cause many problems, including wasting resources, making maintenance difficult, and hindering performance. That's why having a great database schema design is a crucial part of effective data management.
|
4 |
| - |
5 |
| -There are few things to focus on when creating a database schema: |
6 |
| - |
7 |
| -- How the data will be stored (what database will be used)? |
8 |
| -- The query performance. |
9 |
| -- How much hardware it will take? |
| 4 | +By defining categories of data and relationships between those categories, database schema design makes data much easier to retrieve, consume, manipulate, and interpret. |
| 5 | +Without a clean, efficient, consistent database schema, you’ll struggle to make the best use of your enterprise data. For example, the same data might be duplicated in multiple locations—or even worse, might be inconsistent between these locations. |
10 | 6 |
|
11 | 7 | ### Type of database
|
12 | 8 |
|
@@ -39,11 +35,24 @@ One of the key points to establish a good schema design (especially, if you are
|
39 | 35 |
|
40 | 36 | In general, there are few `rules` you can follow to better design your schema:
|
41 | 37 |
|
42 |
| -1. Favor embedding over referencing unless there is a compelling reason not to. |
43 |
| -2. Needing to access an object on its own is a compelling reason not to embed. |
44 |
| -3. Avoid JOINs and $lookups if they can be avoided, but don't be afraid if they can provide a better schema design. |
45 |
| -4. How you model your data depends _entirely_ on your particular application's data access patterns. |
| 38 | +##### 1. Favor embedding over referencing unless there is a compelling reason not to. |
| 39 | + |
| 40 | +Embedded documents are an efficient and clean way to store related data, especially data that's regularly accessed together. The more often a given workload can retrieve a single document and have all the data it needs, the more consistently high-performance your application will be. |
| 41 | + |
| 42 | +##### 2. Needing to access an object on its own is a compelling reason not to embed. |
| 43 | + |
| 44 | +Separate data that can be referred to from multiple places into its own collection. |
| 45 | +This is not so much a "storage space" issue as it is a "data consistency" issue. If many records will refer to the same data it is more efficient and less error prone to update a single record and keep references to it in other places. |
| 46 | + |
| 47 | +##### 3. Avoid JOINs and $lookups if they can be avoided, but don't be afraid if they can provide a better schema design. |
| 48 | + |
| 49 | +Having a JOIN or $lookup means you are doing some kind of search in your database for the corresponding field and that operation takes time. So if you embed your data in a single object, you will spare this operation, and your query can be much faster and cleaner. |
| 50 | + |
| 51 | +##### 4. How you model your data depends _entirely_ on your particular application's data access patterns. |
| 52 | + |
| 53 | +This means that no matter what you read or watch, you may still need to make few changes to your schema based on your own use case and application. |
46 | 54 |
|
47 | 55 | ## Resources
|
48 | 56 |
|
49 |
| -- [schema design best practices](https://www.mongodb.com/developer/article/mongodb-schema-design-best-practices/) |
| 57 | +- [Schema design best practices](https://www.mongodb.com/developer/article/mongodb-schema-design-best-practices/) |
| 58 | +- [Guide to database schema design](https://www.xplenty.com/blog/complete-guide-to-database-schema-design-guide/) |
0 commit comments