Skip to content

Commit ddd2df7

Browse files
committed
r1.1 fix
1 parent fca0b0e commit ddd2df7

File tree

2 files changed

+25
-16
lines changed
  • module3-crud-and-data-models

2 files changed

+25
-16
lines changed

module3-crud-and-data-models/r1.1-principles-of-setting-up-your-schema/README.md

Lines changed: 20 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,8 @@
11
## Principles of setting up your schema
22

33
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.
106

117
### Type of database
128

@@ -39,11 +35,24 @@ One of the key points to establish a good schema design (especially, if you are
3935

4036
In general, there are few `rules` you can follow to better design your schema:
4137

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.
4654

4755
## Resources
4856

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/)

module3-crud-and-data-models/r3-model-view-controller/README.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -58,6 +58,11 @@ const post = new mongoose.Schema({
5858
module.exports = mongoose.model("Post", post);
5959
```
6060

61+
### Views
62+
63+
In this folder, you can write HTML code for displaying a web page on the web browser. You can send the data from the controller to view for displaying data dynamically.
64+
In a back-end application, views are usually not implemented and rather we create a front-end app using maybe `React` to call our `api` end-points to manipulate and dispaly the data in the back-end.
65+
6166
### Controllers
6267

6368
Controllers are the layer between the Model and the View. the views can use the controllers to `add`, `read`, `delete`, ...etc data.
@@ -83,11 +88,6 @@ router.get('/posts', (req, res) => {
8388
});
8489
```
8590

86-
### Views
87-
88-
In this folder, you can write HTML code for displaying a web page on the web browser. You can send the data from the controller to view for displaying data dynamically.
89-
In a back-end application, views are usually not implemented and rather we create a front-end app using maybe `React` to call our `api` end-points to manipulate and dispaly the data in the back-end.
90-
9191
## Resources
9292

9393
- [MVC Architecture with NodeJS and mongoose](https://medium.com/geekculture/mvc-architecture-with-express-server-e35aedfe7889)

0 commit comments

Comments
 (0)