[MUSIC]
أعتقد الآن، رأسك موبوء بالمونغوز أم أنه منجيز؟
حسنا، أنا لست تخصصا في اللغة الإنجليزية، لذلك ليس لدي أي فكرة ما هو الجمع. على
أي حال، وهذا يقودنا إلى موضوع هذه المحاضرة، السكان النمس.
ما هو بالضبط السكان النمس
وكيف هو مفيد في التطبيق السريع لدينا؟
دعونا نتحدث عن ذلك بعد ذلك.
كما أدركنا،
لم يتم تصميم قواعد بيانات المستندات، وقواعد بيانات NoSQL، مع الأخذ في الاعتبار العلاقات.
يتم تخزين كل ما تحتاجه في مستند بالكامل داخل المستند.
حسنا، هذا هو إلى حد كبير الطريقة التي تعمل بها الأشياء مع قواعد بيانات NoSQL مثل MongoDB.
لذلك لم يكن لديك دعم للعلاقات التي قد تكون
أكثر دراية بها من عالم قاعدة البيانات العلائقية.
حيث لديك سجلات ومن ثم السجلات يمكن الرجوع إلى سجلات أخرى وهلم جرا.
ثم تقوم بالانضمام من أجل الانضمام إلى المعلومات من السجلات وهلم جرا.
لذلك هذا النوع من الدعم غير موجود في قواعد بيانات NoSQL،
على الأقل إلى حد كبير.
اتخذ MongoDB بضع خطوات في هذا الاتجاه، حتى مع قواعد بيانات NoSQL.
ولكن بشكل عام، تتوقع قواعد بيانات الوثائق أن تكون جميع الوثائق قائمة بذاتها.
مما يعني أن جميع المعلومات المطلوبة موجودة ضمن نفس المستند.
الآن بالطبع، هناك حالات حيث لديك وثائق أخرى
تحتوي بالفعل على المعلومات.
وقد ترغب في سحب تلك المعلومات إلى مستندك الحالي،
بدلاً من تكرار تلك المعلومات.
لذلك هذا هو المكان الذي
يسمح لك MongoDB أو Mongoose بتخزين المراجع إلى مستندات أخرى داخل مستند حالي.
يتم المرجع إلى المستند الآخر باستخدام ObjectId من ذلك
المستند الآخر.
الآن إذا كان هذا هو الحال، فإن Mongoose يسمح لك بإجراء طريقة
لأخذ المعلومات من المستند الآخر ثم إرفاقها
داخل المستند الصحيح باستخدام دعم سكان Mongoose.
هذا ما سنناقشه بمزيد من التفصيل.
النمس نفسه، كما ندرك، كونه وحدة بنيت
على رأس MongoDB، لا يحتوي على دعم صريح
للصلات، الطريقة التي نتحدث بها عن الصلات في عالم SQL.
لفهم كيف يساعدنا هذا الرجوع للمستند الآخر في مستند
وكيف يتم تنظيمه بالفعل، دعونا نلقي نظرة على مثال.
في هذا المثال، سنلقي نظرة على وثيقة الأطباق التي
كنا نستخدمها في ممارستنا.
في وثائق الأطباق التي نخزنها على جانب الخادم،
لاحظنا أننا أيضًا نخزن التعليقات.
وضمن التعليقات، نقوم أيضًا بتخزين حقل مؤلف داخل التعليقات.
ويحتوي حقل المؤلف صراحة على اسم الشخص الذي
قدم هذا التعليق المحدد.
الآن، لأن لدينا بالفعل وثيقة المستخدمين
داخل قاعدة البيانات لدينا، كما رأينا في هذه الوحدة.
لقد قمنا بتوسيع خادم الخبراء لدينا لدعم المستخدمين، وبالتالي،
يمكنك تسجيل مستخدم وأنه يمكنك مصادقة المستخدمين وهلم جرا.
لذلك يمكن لمستند المستخدم أن يحمل معلومات إضافية حول المستخدم بالفعل.
وهكذا عندما يتم نشر تعليق من قبل المستخدم،
بدلا من تخزين اسم المستخدم داخل التعليق نفسه،
لماذا لا يكون لديك إشارة إلى المستخدم المحدد الذي نشر التعليق؟
وهذا مفيد ليس فقط من حيث القدرة على
التعامل مع حقيقة أن هذا التعليق يتم نشره من قبل المستخدم المحدد.
فيما بعد، سنرى أنه إذا كنت بحاجة إلى السماح للمستخدمين بتعديل
المستندات أو حذفها، فقد ترغب في تقييد
نوع تشغيل مستخدم معين على التعليقات التي
نشرها ذلك المستخدم المحدد في وقت سابق فقط.
على الرغم من أننا نستخدم المستندات الفرعية داخل مستند Mongo الخاص بنا.
إذا استطعنا الرجوع إلى مستند آخر في المستند الفرعي باستخدام Objectids،
فإن Mongo يساعدنا على القيام بعدد هذه
المعلومات من المستند الآخر إلى المستند الحالي.
إذاً هذا هو المكان الذي يأتي فيه سكان المنغوس لإنقاذنا
مع أخذ هذه الفكرة أبعد من ذلك، اسمحوا لي أن تظهر لك
مثالا مفصلا من مخطط التعليق الذي حددناه في وقت سابق.
لذلك في التعليقات، لدينا بالفعل حقل التصنيف وحقل
التعليق الذي حددناه بالفعل هناك.
كما اعتدنا على الحصول على حقل المؤلف في وقت سابق.
لحقل المؤلف في وقت سابق، كنا تخزين المؤلف
كسلسلة و، القيمة الافتراضية أيضا للمؤلف.
الآن في تخزين المؤلف كسلسلة نوع، إذا قمنا الآن
بتحويل المؤلف إلى نوع من mongoose.schema.types.Objectid.
مما يعني أن حقل المؤلف الآن سيحتوي على ObjectID،
وهو مرجع لمستند مستخدم.
كيف تتأكد من أن هذا يشير إلى مستند مستخدم؟
لذلك هذا هو المكان الذي تسمى هذه الخاصية الإضافية ref، والتي تحدد
أن مخطط المستند الذي تشير إليه هنا هو من النوع والمستخدم
والمخطط والنموذج الذي قمنا بإضافته مسبقًا.
لذلك في هذه الحالة، يتم الآن توسيع مخطط التعليق لتخزين معلومات المؤلف،
ولكن معلومات المؤلف في شكل ObjectID.
وهو مرجع لمستند المستخدم الذي تم تخزينه بالفعل في قاعدة البيانات الخاصة بنا.
الآن، كيف يساعدنا هذا؟
هذا هو المكان، كما قلت، السكان النمس يأتي لمساعدتنا.
إذن كيف يعمل سكان (مونغوس)؟
مع سكان Mongoose، فإن الطريقة التي يعمل بها سكان Mongoose هي
أنه يستبدل تلقائيًا المسارات المحددة داخل مستند حالي.
الذي يحتوي على إشارة إلى وثيقة أخرى من المعلومات من تلك الوثيقة الأخرى.
لذلك في مخطط التعليق، على سبيل المثال، لديك حقل مؤلف
يشير إلى ObjectId لمستند المستخدم الموجود بالفعل في قاعدة البيانات الخاصة بك.
لذلك مع سكان Mongoose، عندما تطلب من Mongoose ملء مستند الطبق هذا،
فإنه سيتم ملء المعلومات حول المؤلف في حقل التعليق
من مستند المستخدم.
لذلك سيتم
جلب المعلومات حول المؤلف المحدد الذي يشار إليه هناك وإضافتها إلى مستند الطبق الخاص بك.
وسيتم بناء الوثيقة المركبة ومن ثم إرسالها مرة أخرى إليك.
كيف نضمن حدوث ذلك؟
هذا هو المكان الذي يساعدنا فيه الإحالة التبادلية مع ObjectID، كما رأينا،.
كيف يحدث السكان في الواقع في التعليمات البرمجية؟
نلقي نظرة على كيفية ملء،
على سبيل المثال، وثيقة الأطباق التي رأيناها للتو في وقت سابق.
في وقت سابق كنا نفعل dusines.Find للعثور على جميع الأطباق في قاعدة البيانات لدينا.
الآن، بمجرد العثور على وثيقة الأطباق، ثم يمكنك أن تقول تعبئة.
ومن ثم توفير داخل ملء، كمعلمة،
الحقل المحدد الذي يحتاج إلى ملء.
حتى هنا نحن نحدد التعليقات. المؤلف.
الآن التوقع هو أن حقل التعليقات. المؤلف هو
في الواقع Ojectid الذي يشير إلى مستند المستخدم.
وهذه هي الطريقة التي قمنا بها بإعداد مخطط التعليق لدينا بالفعل.
لذلك فإن هذه المكالمة التي نؤديها هنا سوف تذهب ثم
تجلب من قاعدة البيانات كل سجل المؤلف الفردية أو سجل المستخدم.
ثم خذ مستند المستخدم هذا وقم
بملئه في مستند الأطباق لإنشاء المستند المركب من هنا.
وبعد ذلك، بالطبع،
هناك بعض المعالجة اللاحقة للبيانات التي حصلت عليها.
ومن ثم الرد أو إرجاع البيانات إلى العميل يمكن أن يحدث في هذه المرحلة.
ولكن بالطبع، اسمحوا لي أن أحذركم أن هذه العملية السكانية
ليست مهمة سهلة للخادم للقيام بها.
لأن كل طبق واحد، سيكون لديك لفحص كل تعليق.
ثم لكل تعليق، ثم تحتاج إلى معرفة ObjectID
للمستخدم.
ثم تذهب وجلب مستند المستخدم هذا
ثم تعبئته داخل مستند الطبق.
وبعد ذلك، يجب أن يتكرر
ذلك لكل تعليق واحد موجود في وثيقة الأطباق.
وهذا يعني أساسا أنه سيستغرق وقتا أطول بكثير لجانب الخادم
لإكمال الطلب وإرسال المعلومات مرة أخرى إلى جانب العميل.
لذلك أود أن أقترح عليك استخدام ملء بحكمة جدا.
يجب عليك استخدامه فقط في الظروف التي تحتاج فيها بالفعل إلى تلك المعلومات.
إذا، على سبيل المثال، كنت ببساطة بناء القائمة لمطعمك.
عندما تقوم فقط بإنشاء القائمة
لمطعمك، قد لا تحتاج حقًا إلى ملء المعلومات حول مؤلف كل
تعليق في مستند التعليق على الإطلاق.
لأنه عندما كنت مجرد تقديم القائمة لمطعمك،
فإنك لن يكون عرض التعليقات على هذا الطبق المحدد.
ولكن بدلاً من ذلك، إذا كان المستخدم يقوم بفحص طبق معين
ويريد رؤية التعليقات في هذه المرحلة،
فقد ترغب في تنفيذ طلب جانب الخادم.
ومن ثم جلب معلومات التعليق مع معلومات المؤلف الأخرى
المأهولة والحصول على ذلك للاستخدام داخل جانب عملائنا.
لذلك مرة أخرى، تعبئة هو وسيلة رائعة للقيام الأشياء عند الحاجة،
ولكن استخدامها بشكل قضائي جدا، فقط عندما كنت حقا بحاجة إلى المعلومات.
لذا فإن المرونة التي تعبأ توفر
لنا هي حقيقة أننا لسنا بحاجة إلى ملء عندما لا نضطر إلى ذلك.
ولكن يمكننا ملء المعلومات عندما نحتاج حقا تلك المعلومات.
مع هذا الفهم السريع للسكان النمس،
دعونا ننتقل إلى التمرين حيث سنقوم بتعديل مخطط الأطباق،
مخطط التعليقات داخل مخطط الأطباق.
ثم استخدم Mongoose polate لملء المعلومات داخل أطباقنا
عندما نقوم بإرجاع معلومات الطبق إلى جانب الخادم.
أيضا، هذا يعني أيضا أنه عند إضافة تعليق إلى طبق معين،
يجب التقاط مؤلف معلومات التعليق على جانب الخادم.
الآن، يحدث ذلك أن الطريقة التي قمنا بتطوير خوادمنا،
لدينا بالفعل هذه المعلومات التي يتم توفيرها لنا.
عندما نقوم بمصادقة المستخدم، يتم تحميل معلومات المستخدم بالفعل في
كل طلب يأتي من جانب العميل.
وهكذا يستخدمون معلومات المستخدم المتاحة لنا.
لذلك عندما نقوم بنشر التعليق على جانب الخادم، سنقوم أيضًا
بالتقاط معرف المستخدم ثم تخزينه في حقل المؤلف لمخطط التعليق.
يجب أن يتم ذلك تلقائيًا على جانب الخادم.
يجب عدم السماح للعميل بملء حقل المؤلف بشكل صريح.
ولكن يجب على جانب الخادم التحقق من صحة المستخدم وفقط
للمستخدمين الذين تم تسجيل الدخول، ستسمح لهم، أولاً وقبل كل شيء، بنشر التعليقات.
ثم عندما يقومون بنشر التعليقات،
ستقوم تلقائيًا بملء حقل المؤلف الخاص بوثيقة التعليق هذه عن
طريق استبدال حقل المؤلف بـ ObjectId للمستخدم.
الآن، في التمرين، سوف تراني أفعل ذلك.
لذا احترس من ذلك الشيء المحدد في التمرين.
مع هذا، ونحن الانتهاء من هذه المحاضرة،
دعونا المضي قدما في ممارسة لدراسة استخدام السكان النمس.
[ موسيقى]