1
00:00:00,000 --> 00:00:04,652
[MUSIC]

2
00:00:04,652 --> 00:00:11,190
أعتقد الآن، رأسك موبوء بالمونغوز أم أنه منجيز؟

3
00:00:11,190 --> 00:00:16,500
حسنا، أنا لست تخصصا في اللغة الإنجليزية، لذلك ليس لدي أي فكرة ما هو الجمع. على

4
00:00:16,500 --> 00:00:22,770
أي حال، وهذا يقودنا إلى موضوع هذه المحاضرة، السكان النمس.

5
00:00:22,770 --> 00:00:25,120
ما هو بالضبط السكان النمس

6
00:00:25,120 --> 00:00:29,800
وكيف هو مفيد في التطبيق السريع لدينا؟

7
00:00:29,800 --> 00:00:31,190
دعونا نتحدث عن ذلك بعد ذلك.

8
00:00:33,100 --> 00:00:38,275
كما أدركنا،

9
00:00:38,275 --> 00:00:41,767
لم يتم تصميم قواعد بيانات المستندات، وقواعد بيانات NoSQL، مع الأخذ في الاعتبار العلاقات.

10
00:00:41,767 --> 00:00:46,570
يتم تخزين كل ما تحتاجه في مستند بالكامل داخل المستند.

11
00:00:46,570 --> 00:00:53,650
حسنا، هذا هو إلى حد كبير الطريقة التي تعمل بها الأشياء مع قواعد بيانات NoSQL مثل MongoDB.

12
00:00:53,650 --> 00:00:58,490
لذلك لم يكن لديك دعم للعلاقات التي قد تكون

13
00:00:58,490 --> 00:01:03,065
أكثر دراية بها من عالم قاعدة البيانات العلائقية.

14
00:01:03,065 --> 00:01:08,060
حيث لديك سجلات ومن ثم السجلات يمكن الرجوع إلى سجلات أخرى وهلم جرا.

15
00:01:08,060 --> 00:01:12,510
ثم تقوم بالانضمام من أجل الانضمام إلى المعلومات من السجلات وهلم جرا.

16
00:01:12,510 --> 00:01:17,030
لذلك هذا النوع من الدعم غير موجود في قواعد بيانات NoSQL،

17
00:01:17,030 --> 00:01:19,010
على الأقل إلى حد كبير.

18
00:01:19,010 --> 00:01:25,120
اتخذ MongoDB بضع خطوات في هذا الاتجاه، حتى مع قواعد بيانات NoSQL.

19
00:01:25,120 --> 00:01:31,030
ولكن بشكل عام، تتوقع قواعد بيانات الوثائق أن تكون جميع الوثائق قائمة بذاتها.

20
00:01:31,030 --> 00:01:36,740
مما يعني أن جميع المعلومات المطلوبة موجودة ضمن نفس المستند.

21
00:01:36,740 --> 00:01:41,270
الآن بالطبع، هناك حالات حيث لديك وثائق أخرى

22
00:01:41,270 --> 00:01:43,657
تحتوي بالفعل على المعلومات.

23
00:01:43,657 --> 00:01:47,561
وقد ترغب في سحب تلك المعلومات إلى مستندك الحالي،

24
00:01:47,561 --> 00:01:50,580
بدلاً من تكرار تلك المعلومات.

25
00:01:50,580 --> 00:01:57,390
لذلك هذا هو المكان الذي

26
00:01:57,390 --> 00:02:04,290
يسمح لك MongoDB أو Mongoose بتخزين المراجع إلى مستندات أخرى داخل مستند حالي.

27
00:02:04,290 --> 00:02:08,953
يتم المرجع إلى المستند الآخر باستخدام ObjectId من ذلك

28
00:02:08,953 --> 00:02:10,125
المستند الآخر.

29
00:02:10,125 --> 00:02:14,773
الآن إذا كان هذا هو الحال، فإن Mongoose يسمح لك بإجراء طريقة

30
00:02:14,773 --> 00:02:19,588
لأخذ المعلومات من المستند الآخر ثم إرفاقها

31
00:02:19,588 --> 00:02:25,010
داخل المستند الصحيح باستخدام دعم سكان Mongoose.

32
00:02:25,010 --> 00:02:28,230
هذا ما سنناقشه بمزيد من التفصيل.

33
00:02:28,230 --> 00:02:33,227
النمس نفسه، كما ندرك، كونه وحدة بنيت

34
00:02:33,227 --> 00:02:38,336
على رأس MongoDB، لا يحتوي على دعم صريح

35
00:02:38,336 --> 00:02:43,135
للصلات، الطريقة التي نتحدث بها عن الصلات في عالم SQL.

36
00:02:43,135 --> 00:02:48,471
لفهم كيف يساعدنا هذا الرجوع للمستند الآخر في مستند

37
00:02:48,471 --> 00:02:53,210
وكيف يتم تنظيمه بالفعل، دعونا نلقي نظرة على مثال.

38
00:02:53,210 --> 00:02:58,420
في هذا المثال، سنلقي نظرة على وثيقة الأطباق التي

39
00:02:58,420 --> 00:03:01,210
كنا نستخدمها في ممارستنا.

40
00:03:01,210 --> 00:03:04,540
في وثائق الأطباق التي نخزنها على جانب الخادم،

41
00:03:04,540 --> 00:03:07,590
لاحظنا أننا أيضًا نخزن التعليقات.

42
00:03:07,590 --> 00:03:12,366
وضمن التعليقات، نقوم أيضًا بتخزين حقل مؤلف داخل التعليقات.

43
00:03:12,366 --> 00:03:16,750
ويحتوي حقل المؤلف صراحة على اسم الشخص الذي

44
00:03:16,750 --> 00:03:19,890
قدم هذا التعليق المحدد.

45
00:03:19,890 --> 00:03:24,961
الآن، لأن لدينا بالفعل وثيقة المستخدمين

46
00:03:24,961 --> 00:03:30,453
داخل قاعدة البيانات لدينا، كما رأينا في هذه الوحدة.

47
00:03:30,453 --> 00:03:35,151
لقد قمنا بتوسيع خادم الخبراء لدينا لدعم المستخدمين، وبالتالي،

48
00:03:35,151 --> 00:03:40,440
يمكنك تسجيل مستخدم وأنه يمكنك مصادقة المستخدمين وهلم جرا.

49
00:03:40,440 --> 00:03:45,790
لذلك يمكن لمستند المستخدم أن يحمل معلومات إضافية حول المستخدم بالفعل.

50
00:03:46,810 --> 00:03:49,302
وهكذا عندما يتم نشر تعليق من قبل المستخدم،

51
00:03:49,302 --> 00:03:53,043
بدلا من تخزين اسم المستخدم داخل التعليق نفسه،

52
00:03:53,043 --> 00:03:57,360
لماذا لا يكون لديك إشارة إلى المستخدم المحدد الذي نشر التعليق؟

53
00:03:58,360 --> 00:04:02,570
وهذا مفيد ليس فقط من حيث القدرة على

54
00:04:02,570 --> 00:04:07,680
التعامل مع حقيقة أن هذا التعليق يتم نشره من قبل المستخدم المحدد.

55
00:04:07,680 --> 00:04:13,934
فيما بعد، سنرى أنه إذا كنت بحاجة إلى السماح للمستخدمين بتعديل

56
00:04:13,934 --> 00:04:19,126
المستندات أو حذفها، فقد ترغب في تقييد

57
00:04:19,126 --> 00:04:24,436
نوع تشغيل مستخدم معين على التعليقات التي

58
00:04:24,436 --> 00:04:28,937
نشرها ذلك المستخدم المحدد في وقت سابق فقط.

59
00:04:28,937 --> 00:04:36,649
على الرغم من أننا نستخدم المستندات الفرعية داخل مستند Mongo الخاص بنا.

60
00:04:36,649 --> 00:04:42,292
إذا استطعنا الرجوع إلى مستند آخر في المستند الفرعي باستخدام Objectids،

61
00:04:42,292 --> 00:04:45,415
فإن Mongo يساعدنا على القيام بعدد هذه

62
00:04:45,415 --> 00:04:50,450
المعلومات من المستند الآخر إلى المستند الحالي.

63
00:04:50,450 --> 00:04:54,370
إذاً هذا هو المكان الذي يأتي فيه سكان المنغوس لإنقاذنا

64
00:04:54,370 --> 00:04:57,770
مع أخذ هذه الفكرة أبعد من ذلك، اسمحوا لي أن تظهر لك

65
00:04:57,770 --> 00:05:02,600
مثالا مفصلا من مخطط التعليق الذي حددناه في وقت سابق.

66
00:05:02,600 --> 00:05:06,850
لذلك في التعليقات، لدينا بالفعل حقل التصنيف وحقل

67
00:05:06,850 --> 00:05:10,080
التعليق الذي حددناه بالفعل هناك.

68
00:05:10,080 --> 00:05:13,320
كما اعتدنا على الحصول على حقل المؤلف في وقت سابق.

69
00:05:13,320 --> 00:05:18,133
لحقل المؤلف في وقت سابق، كنا تخزين المؤلف

70
00:05:18,133 --> 00:05:23,270
كسلسلة و، القيمة الافتراضية أيضا للمؤلف.

71
00:05:23,270 --> 00:05:28,285
الآن في تخزين المؤلف كسلسلة نوع، إذا قمنا الآن

72
00:05:28,285 --> 00:05:34,200
بتحويل المؤلف إلى نوع من mongoose.schema.types.Objectid.

73
00:05:34,200 --> 00:05:39,350
مما يعني أن حقل المؤلف الآن سيحتوي على ObjectID،

74
00:05:39,350 --> 00:05:42,870
وهو مرجع لمستند مستخدم.

75
00:05:42,870 --> 00:05:46,090
كيف تتأكد من أن هذا يشير إلى مستند مستخدم؟

76
00:05:46,090 --> 00:05:51,500
لذلك هذا هو المكان الذي تسمى هذه الخاصية الإضافية ref، والتي تحدد

77
00:05:51,500 --> 00:05:56,160
أن مخطط المستند الذي تشير إليه هنا هو من النوع والمستخدم

78
00:05:56,160 --> 00:05:59,590
والمخطط والنموذج الذي قمنا بإضافته مسبقًا.

79
00:05:59,590 --> 00:06:05,144
لذلك في هذه الحالة، يتم الآن توسيع مخطط التعليق لتخزين معلومات المؤلف،

80
00:06:05,144 --> 00:06:08,706
ولكن معلومات المؤلف في شكل ObjectID.

81
00:06:08,706 --> 00:06:15,480
وهو مرجع لمستند المستخدم الذي تم تخزينه بالفعل في قاعدة البيانات الخاصة بنا.

82
00:06:15,480 --> 00:06:17,750
الآن، كيف يساعدنا هذا؟

83
00:06:17,750 --> 00:06:22,667
هذا هو المكان، كما قلت، السكان النمس يأتي لمساعدتنا.

84
00:06:22,667 --> 00:06:25,120
إذن كيف يعمل سكان (مونغوس)؟

85
00:06:25,120 --> 00:06:30,150
مع سكان Mongoose، فإن الطريقة التي يعمل بها سكان Mongoose هي

86
00:06:30,150 --> 00:06:35,363
أنه يستبدل تلقائيًا المسارات المحددة داخل مستند حالي.

87
00:06:35,363 --> 00:06:40,850
الذي يحتوي على إشارة إلى وثيقة أخرى من المعلومات من تلك الوثيقة الأخرى.

88
00:06:40,850 --> 00:06:46,282
لذلك في مخطط التعليق، على سبيل المثال، لديك حقل مؤلف

89
00:06:46,282 --> 00:06:53,070
يشير إلى ObjectId لمستند المستخدم الموجود بالفعل في قاعدة البيانات الخاصة بك.

90
00:06:53,070 --> 00:06:58,963
لذلك مع سكان Mongoose، عندما تطلب من Mongoose ملء مستند الطبق هذا،

91
00:06:58,963 --> 00:07:03,820
فإنه سيتم ملء المعلومات حول المؤلف في حقل التعليق

92
00:07:03,820 --> 00:07:05,240
من مستند المستخدم.

93
00:07:05,240 --> 00:07:09,447
لذلك سيتم

94
00:07:09,447 --> 00:07:12,130
جلب المعلومات حول المؤلف المحدد الذي يشار إليه هناك وإضافتها إلى مستند الطبق الخاص بك.

95
00:07:12,130 --> 00:07:16,820
وسيتم بناء الوثيقة المركبة ومن ثم إرسالها مرة أخرى إليك.

96
00:07:16,820 --> 00:07:19,370
كيف نضمن حدوث ذلك؟

97
00:07:19,370 --> 00:07:25,020
هذا هو المكان الذي يساعدنا فيه الإحالة التبادلية مع ObjectID، كما رأينا،.

98
00:07:25,020 --> 00:07:30,890
كيف يحدث السكان في الواقع في التعليمات البرمجية؟

99
00:07:30,890 --> 00:07:33,350
نلقي نظرة على كيفية ملء،

100
00:07:33,350 --> 00:07:38,090
على سبيل المثال، وثيقة الأطباق التي رأيناها للتو في وقت سابق.

101
00:07:38,090 --> 00:07:43,650
في وقت سابق كنا نفعل dusines.Find للعثور على جميع الأطباق في قاعدة البيانات لدينا.

102
00:07:43,650 --> 00:07:48,645
الآن، بمجرد العثور على وثيقة الأطباق، ثم يمكنك أن تقول تعبئة.

103
00:07:48,645 --> 00:07:52,647
ومن ثم توفير داخل ملء، كمعلمة،

104
00:07:52,647 --> 00:07:56,130
الحقل المحدد الذي يحتاج إلى ملء.

105
00:07:56,130 --> 00:07:59,380
حتى هنا نحن نحدد التعليقات. المؤلف.

106
00:07:59,380 --> 00:08:02,270
الآن التوقع هو أن حقل التعليقات. المؤلف هو

107
00:08:02,270 --> 00:08:06,550
في الواقع Ojectid الذي يشير إلى مستند المستخدم.

108
00:08:06,550 --> 00:08:10,502
وهذه هي الطريقة التي قمنا بها بإعداد مخطط التعليق لدينا بالفعل.

109
00:08:10,502 --> 00:08:16,418
لذلك فإن هذه المكالمة التي نؤديها هنا سوف تذهب ثم

110
00:08:16,418 --> 00:08:24,937
تجلب من قاعدة البيانات كل سجل المؤلف الفردية أو سجل المستخدم.

111
00:08:24,937 --> 00:08:27,457
ثم خذ مستند المستخدم هذا وقم

112
00:08:27,457 --> 00:08:33,505
بملئه في مستند الأطباق لإنشاء المستند المركب من هنا.

113
00:08:33,505 --> 00:08:35,525
وبعد ذلك، بالطبع،

114
00:08:35,525 --> 00:08:39,579
هناك بعض المعالجة اللاحقة للبيانات التي حصلت عليها.

115
00:08:39,579 --> 00:08:44,640
ومن ثم الرد أو إرجاع البيانات إلى العميل يمكن أن يحدث في هذه المرحلة.

116
00:08:44,640 --> 00:08:49,110
ولكن بالطبع، اسمحوا لي أن أحذركم أن هذه العملية السكانية

117
00:08:49,110 --> 00:08:52,020
ليست مهمة سهلة للخادم للقيام بها.

118
00:08:52,020 --> 00:08:56,825
لأن كل طبق واحد، سيكون لديك لفحص كل تعليق.

119
00:08:56,825 --> 00:09:01,385
ثم لكل تعليق، ثم تحتاج إلى معرفة ObjectID

120
00:09:01,385 --> 00:09:02,034
للمستخدم.

121
00:09:02,034 --> 00:09:04,580
ثم تذهب وجلب مستند المستخدم هذا

122
00:09:04,580 --> 00:09:07,203
ثم تعبئته داخل مستند الطبق.

123
00:09:07,203 --> 00:09:09,329
وبعد ذلك، يجب أن يتكرر

124
00:09:09,329 --> 00:09:13,113
ذلك لكل تعليق واحد موجود في وثيقة الأطباق.

125
00:09:13,113 --> 00:09:18,437
وهذا يعني أساسا أنه سيستغرق وقتا أطول بكثير لجانب الخادم

126
00:09:18,437 --> 00:09:23,720
لإكمال الطلب وإرسال المعلومات مرة أخرى إلى جانب العميل.

127
00:09:23,720 --> 00:09:31,020
لذلك أود أن أقترح عليك استخدام ملء بحكمة جدا.

128
00:09:31,020 --> 00:09:35,410
يجب عليك استخدامه فقط في الظروف التي تحتاج فيها بالفعل إلى تلك المعلومات.

129
00:09:36,590 --> 00:09:42,529
إذا، على سبيل المثال، كنت ببساطة بناء القائمة لمطعمك.

130
00:09:42,529 --> 00:09:46,522
عندما تقوم فقط بإنشاء القائمة

131
00:09:46,522 --> 00:09:51,267
لمطعمك، قد لا تحتاج حقًا إلى ملء المعلومات حول مؤلف كل

132
00:09:51,267 --> 00:09:54,010
تعليق في مستند التعليق على الإطلاق.

133
00:09:54,010 --> 00:09:57,270
لأنه عندما كنت مجرد تقديم القائمة لمطعمك،

134
00:09:57,270 --> 00:10:01,730
فإنك لن يكون عرض التعليقات على هذا الطبق المحدد.

135
00:10:01,730 --> 00:10:06,457
ولكن بدلاً من ذلك، إذا كان المستخدم يقوم بفحص طبق معين

136
00:10:06,457 --> 00:10:09,804
ويريد رؤية التعليقات في هذه المرحلة،

137
00:10:09,804 --> 00:10:13,660
فقد ترغب في تنفيذ طلب جانب الخادم.

138
00:10:13,660 --> 00:10:19,383
ومن ثم جلب معلومات التعليق مع معلومات المؤلف الأخرى

139
00:10:19,383 --> 00:10:24,540
المأهولة والحصول على ذلك للاستخدام داخل جانب عملائنا.

140
00:10:24,540 --> 00:10:30,240
لذلك مرة أخرى، تعبئة هو وسيلة رائعة للقيام الأشياء عند الحاجة،

141
00:10:30,240 --> 00:10:35,610
ولكن استخدامها بشكل قضائي جدا، فقط عندما كنت حقا بحاجة إلى المعلومات.

142
00:10:35,610 --> 00:10:38,370
لذا فإن المرونة التي تعبأ توفر

143
00:10:38,370 --> 00:10:42,540
لنا هي حقيقة أننا لسنا بحاجة إلى ملء عندما لا نضطر إلى ذلك.

144
00:10:42,540 --> 00:10:46,990
ولكن يمكننا ملء المعلومات عندما نحتاج حقا تلك المعلومات.

145
00:10:48,030 --> 00:10:51,450
مع هذا الفهم السريع للسكان النمس،

146
00:10:51,450 --> 00:10:57,280
دعونا ننتقل إلى التمرين حيث سنقوم بتعديل مخطط الأطباق،

147
00:10:57,280 --> 00:10:59,840
مخطط التعليقات داخل مخطط الأطباق.

148
00:10:59,840 --> 00:11:04,730
ثم استخدم Mongoose polate لملء المعلومات داخل أطباقنا

149
00:11:04,730 --> 00:11:09,255
عندما نقوم بإرجاع معلومات الطبق إلى جانب الخادم.

150
00:11:09,255 --> 00:11:15,745
أيضا، هذا يعني أيضا أنه عند إضافة تعليق إلى طبق معين،

151
00:11:16,775 --> 00:11:22,210
يجب التقاط مؤلف معلومات التعليق على جانب الخادم.

152
00:11:22,210 --> 00:11:26,079
الآن، يحدث ذلك أن الطريقة التي قمنا بتطوير خوادمنا،

153
00:11:26,079 --> 00:11:29,740
لدينا بالفعل هذه المعلومات التي يتم توفيرها لنا.

154
00:11:29,740 --> 00:11:34,870
عندما نقوم بمصادقة المستخدم، يتم تحميل معلومات المستخدم بالفعل في

155
00:11:34,870 --> 00:11:37,580
كل طلب يأتي من جانب العميل.

156
00:11:37,580 --> 00:11:41,200
وهكذا يستخدمون معلومات المستخدم المتاحة لنا.

157
00:11:41,200 --> 00:11:46,170
لذلك عندما نقوم بنشر التعليق على جانب الخادم، سنقوم أيضًا

158
00:11:46,170 --> 00:11:52,370
بالتقاط معرف المستخدم ثم تخزينه في حقل المؤلف لمخطط التعليق.

159
00:11:52,370 --> 00:11:55,430
يجب أن يتم ذلك تلقائيًا على جانب الخادم.

160
00:11:55,430 --> 00:12:00,740
يجب عدم السماح للعميل بملء حقل المؤلف بشكل صريح.

161
00:12:00,740 --> 00:12:04,348
ولكن يجب على جانب الخادم التحقق من صحة المستخدم وفقط

162
00:12:04,348 --> 00:12:10,020
للمستخدمين الذين تم تسجيل الدخول، ستسمح لهم، أولاً وقبل كل شيء، بنشر التعليقات.

163
00:12:10,020 --> 00:12:12,688
ثم عندما يقومون بنشر التعليقات،

164
00:12:12,688 --> 00:12:18,392
ستقوم تلقائيًا بملء حقل المؤلف الخاص بوثيقة التعليق هذه عن

165
00:12:18,392 --> 00:12:23,740
طريق استبدال حقل المؤلف بـ ObjectId للمستخدم.

166
00:12:23,740 --> 00:12:25,920
الآن، في التمرين، سوف تراني أفعل ذلك.

167
00:12:25,920 --> 00:12:30,780
لذا احترس من ذلك الشيء المحدد في التمرين.

168
00:12:30,780 --> 00:12:33,245
مع هذا، ونحن الانتهاء من هذه المحاضرة،

169
00:12:33,245 --> 00:12:38,109
دعونا المضي قدما في ممارسة لدراسة استخدام السكان النمس.

170
00:12:38,109 --> 00:12:44,079
[ موسيقى]