[MUSIC PLAYING]
[MUSIC - FERGIE & Q TIP & GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY"]
FERGIE & Q-TIP & GOONROCK: (SINGING) ليلة واحدة فقط،
هي كل ما لدينا، ليلة واحدة فقط، هي كل كل ما لدينا، ليلة واحدة فقط ، هي كل ما
لدينا، ليلة واحدة فقط، هي كل ما لدينا.
حفلة صغيرة لم تقتل أحدًا.
لذلك سنرقص حتى ننسى، ننسى، ننسى.
امم، حفلة صغيرة لم تقتل أحدًا.
هنا الآن، هنا الآن، هي كل ما لدينا. سكيتن-بود-أوب-بوب.
[MUSIC - FERGIE & Q TIP &
GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY"]
(SINGING) حفلة صغيرة لم تقتل أحدًا.
لذلك سنرقص حتى ننسى.
هيا بنا.
حفلة صغيرة لم تقتل أحدًا.
هنا الآن، هي كل ما لدينا.
أوه، حفلة صغيرة لم تقتل أحدًا.
لذلك سنرقص حتى ننسى.
حفلة صغيرة لم تقتل أحدًا.
[MUSIC - FERGIE & Q TIP &
GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY"]
الدمية: [SNORING]
ديفيد ج. مالان: حسنًا.
هذه هي دورة CS50، وهذه هي المحاضرة 8.
وتلك كانت نظرة على ما يُسمى بالهاكاثون الخاص بدورة CS50، هذا التقليد السنوي
الذي ننهي به الفصل الدراسي تقريبًا والذي سيبدأ حوالي الساعة 7:00 مساءً هنا
في كامبريدج، وسينتهي حوالي الساعة 7 صباحًا من اليوم التالي في كامبريدج.
ويتخلل الأمسية قدر لا بأس به من العمل
على المشاريع النهائية، وهو الهدف الأسمى من الأمسية
لمنح الطلاب، بيئة أكاديمية
واجتماعية وتعاونية للغاية حيث يتناولون
إنجازاتهم النهائية في الدورة.
ولكن أيضًا، كما لاحظتم سيكون هناك القليل من اللهو، والطعام
من مطاعم فيليبز، عادةً، حوالي الساعة 9:00 مساءً، وقليلاً من دومينوز بيتزا
حوالي الساعة 1:00 صباحًا.
وبالنسبة لهؤلاء الذين ما زالوا صامدين كالدمية هناك،
سندعوكم إلى وجبة الإفطار في IHOP إذا ما تزال لديكم الطاقة.
بعد ذلك، سنتواجد فيما يُسمى بمعرض CS50، ذروة كل شيء
قمتم به في دورة CS50.
والمزيد حول ذلك في الأسابيع القادمة.
لن أسترسل وأضجركم بكثرة الكلام، ما الذي تحدّثنا عنه في هذه الأسابيع القليلة الماضية؟
حسنًا، تذكرون أنه، على مدار الأسبوعين الماضيين،
قمنا بتقديم ​​برمجة الويب.
وفي الآونة الأخيرة، حاولنا ربط العديد من الموضوعات معًا
من الأسابيع القليلة الماضية.
HTML وCSS وJavaScript، ومن ثم Python، ثم إطار عمل آخر،
جزء آخر من البرامج يُسمى Flask والذي
جعل إنشاء تطبيقات قائمة على الويب تحديدًا أمرًا سهلاً وممكنًا بشكل أكبر.
والمثال الأبسط لذلك الأسبوع الماضي، تذكرون،
بدا إلى حد ما شيئًا كهذا.
وقمتم في هذا الأسبوع الماضي مع المشاكل في أوجه التشابه والاستقصاء،
ببناء تطبيقاتكم القائمة على الويب.
لكنها لا تحتوي إلى حد ما على جميع الأجزاء
التي قد ترغبون في تجمعيها في تطبيق قائم على الويب.
ولذلك فاليوم، سنملأ تلك الفراغات النهائية.
لكن تذكرون أننا نحاول وضع أُطُر لهذه التطبيقات، ليس
كأشياء منفردة أو فقط أدوات قمتم بإنشائها، ولكن كجزء
من نموذج شائع أو منهجية.
وبالفعل، عندما تتعلمون علوم الكمبيوتر وهندسة
البرمجيات، ستبدؤون ملاحظة الأنماط في البرامج،
في التعليمة البرمجية التي تكتبونها.
ويميل الأشخاص إلى تبنّي هذه الأنماط لأنها توفر لكم الوقت.
ومن ثم يمكن لأي شخص أن يتحدث اللغة نفسها، إذا جاز التعبير.
إذن كان MVC هو الاختصار الذي قدمناه الأسبوع الماضي، النموذج والعرض ووحدة التحكم.
وهذا فقط يتحدث إلى هذا النموذج حيث
قمتم بتنظيم نوع معين من تعليمة برمجية في ملف واحد، وأنواع معينة من تعليمة برمجية أخرى
وملف آخر.
إذن تنتقل تعليمة Python البرمجية الخاصة بكم إلى application.py.
تنتقل HTML إلى ملفات HTML الخاصة بكم، وCSS إلى ملفات CSS الخاصة بكم، وهكذا.
ولكن ما لم يكن لدينا في الأسبوع الماضي هو هذا الشيء هنا، بالفعل.
يشير النموذج إلى بياناتكم بشكل عام.
وبينما كان الاستقصاء، الذي يعدّ هو مشكلتكم الأخيرة،
يحتوي على بيانات، عبارة عن ملف CSV يمكن القول إنه عبارة عن نموذج،
إلا أن CSV ليس معبرًا للغاية.
يمكنكم فقط كتابة الصفوف إلى حد كبير إلى ملف نصي، لا يختلف عن جدول البيانات.
لكن لا يمكنكم حقًا الاستعلام عنها.
لا يمكنكم إدراجها أو حذفها بسهولة.
يجب أن تعيدوا إلى حد كبير بناء الملف بالكامل.
وبالفعل، هذا بالضبط ما فعلته سابقًا.
كان أول تطبيق قائم على الويب كتبتُه في السنة الثانية أو السنة الثالثة
الجامعية هو موقع الويب الداخلي للطلاب الجدد.
وكل ما كان متاحًا لي، من الناحية التقنية والنظرية،
هو ملفات CSV.
لم تكن لديّ أي فكرة عن قواعد البيانات، لم أدرك كيف يمكنها
أن تجعل حياتي أسهل بكثير.
لذلك قمتُ بتخزين جميع البيانات خلف هذه الروابط هنا تحديدًا
في ملفات نصية بسيطة للغاية.
لكن اليوم، سنمنحكم قوة أكبر بكثير.
وبشكل خاص، إذا كنتم قادمين إلى الصف مهتمين بأمر
تطبيق CS في حقول أخرى في الطب أو الفنون
أو أي عالم يوجد به بيانات، بشكل خاص،
في STEM وعلوم البيانات وما شابه ذلك، فأدركوا
أن SQL أصبحت بالفعل تلك اللغة القوية بشكل لا يصدق
التي نحل المشاكل بها في تلك المجالات ومجالات كثيرة جدًا.
وفي النهاية، ستكون البنية الخاصة بكم، في هذا الأسبوع القادم--
وهي آخر مجموعة مشاكل CS50 لديكم--
التي وصلتم الآن إلى ذروتها تقريبًا-- هي CD50
Finance، وهو تطبيق قائم على الويب يمكنكم بواسطته شراء الأسهم،
أو "شراء" الأسهم وبيعها.
ولذا ما ستقومون به في الأسبوع القادم هو كتابة تعليمة برمجية
تنفذ تطبيق ويب يشبه هذا حيث
سيكون بمقدوركم أنتم والمستخدمين لديكم التسجيل للحصول على حساب،
وتسجيل الدخول إلى ذلك الحساب.
سيتم منحكم إياه مجانًا، وذلك بفضلنا، 10000 دولار افتراضية.
ومن ثم يمكنكم المضي قدمًا وشراء الأسهم وبيعها عبر الرمز الخاص بها
باستخدام هذا التطبيق.
إذن على سبيل المثال، إذا مضيتُ قدمًا وقمتُ بتسجيل نفسي هنا.
لنقل، اسم المستخدم مالان، كلمة المرور 12345--
لا يجب أن أقول ذلك.
وأمضي قدمًا وأقوم بالتسجيل هنا.
سترون ذلك، بشكل افتراضي، حصلتُ على 10 آلاف دولار المجانية هذه كنقود افتراضية.
أتعلمون ماذا، سأمضي قدمًا وأشتري بنفسي
سهمًا ربما من Netflix، ورمزها هو NFLX.
سأمضي قدمًا وأحاول شراء سهم واحد.
ها هو ذا.
والآن سترون أنه، فقط ليست لديّ نقود قليلة متبقية، حوالي 9600 دولار أمريكي،
الآن أمتلك سهمًا.
وإذا قمنا بإعادة تحميل ذلك على مدار المحاضرة، بصراحة،
قد يرتفع السعر قليلاً أو ينخفض قليلاً
لأن تطبيق الويب هذا الذي ستقومون بإنشائه
سيتحدّث أيضًا إلى API، وهي واجهة برمجة التطبيقات--
إذن بعض مواقع ويب الجهة الخارجية التي توفر لكم بيانات الأسهم.
لذلك تطلبون منها السعر الحالي للسهم.
تمنحنكم إجابة بتنسيق JSON، إذا كنتم
تذكرون مناقشتنا القصيرة حول ذلك.
وستقومون بدمجها، في النهاية، في هذه الواجهة.
إذن سيكون ذلك تتويجًا لكثير من الأفكار
والكتل البنائية التي قد قمتم بتجربتها.
لكننا نحتاج إلى بعض الأجزاء النهائية اليوم.
إذن أولاً وقبل كل شيء ، عندما قمتُ بالتسجيل في هذا الموقع، وقمتُ بإنشاء حساب.
وبالفعل، يمكنني المضي قدمًا وتسجيل الخروج الآن.
وإذا مضيتُ قدمًا وقمتُ بتسجيل الدخول مجددًا--
إذا لم يسرق أحد كلمة المرور الخاصة بي حتى الآن، يمكنني رؤية حسابي وحسابي فقط.
لكننا لم نرَ بعد أي آلية في التعليمة البرمجية
حيث يمكنكم تنفيذ فكرة تسجيل الدخول هذه، أليس كذلك؟
ما هو المنطق الأساسي الذي يعرف من خلاله موقع ويب أنكم تقومون بتسجيل الدخول
أو أنكم لا تقومون بتسجيل الدخول، أليس كذلك؟
بوضوح، عندما انتقلتُ إلى هذا الموقع منذ لحظات،
طلب مني تسجيل الدخول لأنني لم أكن لأنني قمتُ بتسجيل الخروج.
لكن كيف عرف ذلك؟
والآن بعد أن قمتُ بتسجيل الدخول، كيف يعرف أنه يمكنني النقر فوق "علامة اقتباس"
للحصول فقط على علامة اقتباس السهم أو "شراء" فقط لشراء سهم أو "بيعه."
لماذا لا يطلب مني كل مرة أن أنقر فوق رابط تسجيل الدخول مجددًا
باستخدام اسم المستخدم أو كلمة المرور الخاصة بي؟
ما هو رأيكم؟
الجمهور: أليست ملفات تعريف الارتباط الصغيرة التي
تحفظ البيانات داخل ذاكرة التخزين المؤقت الخاصة بمتصفحك وتتيح له معرفة ما يحدث.
ديفيد ج. مالان: أجل، ملفات تعريف الارتباط--
الملفات الصغيرة التي يتم حفظها بواسطة مواقع الويب على جهاز الكمبيوتر الخاص بكم.
الآن احتمالات هي، من المحتمل أن الجميع تقريبًا هنا قد سمعوا بشكل ما،
أن ملفات تعريف الارتباط-- سيئة.
ربما سيئة، تخترق الخصوصية، صحيح؟
حسنًا.
صحيح جدًا.
ولكن لن يعمل معظم ما على الويب بدونها.
إذن شخص آخر، ما الذي تعرفونه عن ماهية ملف تعريف ارتباط؟
ما هو ملف تعريف الارتباط؟
الجمهور: يحفظ معلوماتك بشكل أساسي
وبذلك لا يجب أن تضعها في كل مرة.
ديفيد ج. مالان: أجل.
إنه يحفظ معلوماتكم وبذلك لا يجب أن تضعوها في كل مرة.
إذن في أبسط أشكاله، هو بالضبط مزيج من تلك الإجابات.
حيث عندما أقوم بتسجيل الدخول إلى موقع ويب، يمكنكم
أن تخيلوا أن موقع الويب فقط يتذكر اسم المستخدم وكلمة المرور
فقط عن طريق حفظهم في ملف صغير على جهاز Mac أو جهاز الكمبيوتر الشخصي
بحيث في المرة القادمة التي أزور فيها صفحة ويب،
تقوم فقط بإرسالها تلقائيًا من أجلي، وبذلك لا يجب أن
أكتبها مرارًا وتكرارًا.
الآن دعونا نعثر على خطأ في ذلك.
يبدو أنه سينجح، ولكن ما هو الجانب السلبي من هذا التنفيذ الساذج؟
ما الذي تعتقدونه بشكل بديهي؟
الجمهور: البيانات فقط موجودة هناك؟
ديفيد ج. مالان: البيانات فقط موجودة هناك، أليس كذلك؟
لديّ أشخاص في المكتب أو في المنزل أو في المكتبة
قد لا أريد فقط أن يتمكنوا من الانتقال إلى جهاز الكمبيوتر ذلك
ورؤية هذا الملف النصي الصغير فقط الموجود على جهاز الكمبيوتر الخاص بي.
لأنه بعد ذلك يمكنهم تسجيل الدخول إلى حسابي عن طريق البحث فقط.
لذلك يبدو الأمر مزعجًا إلى حد ما.
في الواقع، هذا أحد تهديدات ملفات تعريف الارتباط.
إذن يتضح أن ملفات تعريف الارتباط أو مواقع الويب لا تميل إلى القيام بذلك، على الأقل،
إذا تم تنفيذها بشكل جيد.
وبدلاً من ذلك تقوم فقط بوضع رقم عشوائي كبير بالفعل على محرك الأقراص الصلبة
أو في ذاكرة الوصول العشوائي أو ذاكرة الكمبيوتر الخاص بكم.
إذن 1234567-- على سبيل المثال، رقم كبير بالفعل ربما مع حروف وأرقام
ربما بعض علامات الترقيم التي تحدّد هويتي بشكل فريد.
وبعد ذلك، في أي وقت أنقر فوق رابط على موقع الويب هذا نفسه،
بعد تسجيل الدخول، فإن متصفحي، بفضل HTTP--
اللغة التي تتحدث بها المتصفحات والخوادم التي ناقشناها منذ بضعة
أسابيع--
فقط يقوم بإرسال ذلك الرقم العشوائي الكبير نفسه بطريقة سحرية
إلى الخادم مرارًا وتكرارًا.
وطالما أن الخادم يتذكر أن هذا الرقم العشوائي الكبير يتوافق
مع اسم المستخدم مالان، فيمكنه معرفة أي حساب ليقوم بعرضه.
ولماذا هو رقم عشوائي كبير؟
لمَ هو ليس فقط كلمة المرور الخاصة بي أو اسم المستخدم الخاص بي؟
لماذا أقترح أنه سيكون رقمًا عشوائيًا كبيرًا؟
الجمهور: في بعض الأحيان يمكن أن يخمنه الأشخاص فقط باستخدام مُنشئ عشوائي.
ديفيد ج. مالان: بالضبط.
في علم الكمبيوتر، العشوائية هي ذلك المكوّن القويّ بشكل لا يصدق.
إذا اخترتم كلمة كبيرة بما فيه الكفاية أو سلسلة كبيرة بما فيه الكفاية
أو جملة، فإن احتمالية أن يتمكّن خصم عشوائي، أو شخص سيئ
على الإنترنت، من تخمين أو يحاول
تخمين أن هذه القيمة منخفضة جدًا فقط، ولن يحدث ذلك في الواقع فقط
في حياتكم من الناحية الإحصائية.
وبذلك تمنحنا هذه العشوائية تلك القدرة.
ولذا يمكنكم التفكير في ذلك بشكل مجازي في العالم الحقيقي
كأنه ختم يدّ.
إذا ذهبتم من قبل إلى منتزه ترفيهي أو حانة
أو نادي حيث يجب أن تظهروا هوياتكم الشخصية أو يجب أن
تدفعوا ثمن التذكرة للدخول، أحيانًا يقومون
بختم أيديكم باستخدام حبر مرئي أو غير مرئي.
وهذا إلى حد كبير لأجل الكفاءة بحيث، بعد ذلك،
عندما تكونون في المنتزه الترفيهي، يمكنكم الخروج والدخول.
ولا يجب أن تعيدوا الدفع أو تعيدوا الختم.
إذا كنتم في الحانة أو النادي، فلا يجب أن تظهروا هوياتكم الشخصية.
يمكنهم التحقق مرة واحدة، ومن ثم بفعالية أكبر يتيحون لكم الدخول والخروج
كما تشاؤون.
لأنكم فقط تظهرون أيديكم أو ختم اليد
الافتراضي هذا للحارس أو حارس البوابة في تلك الأماكن.
إذن تكون ملفات تعريف الارتباط بالضبط هكذا.
بدون علمنا طوال هذا الوقت، في أي وقت تقوم بزيارة موقع ويب قمتَ
بتسجيل الدخول فيه، فإن متصفحك يقوم سرًا ولكن بشكل مفيد
بتقديم ختم اليد إلى ذلك الخادم لتذكيره مَن تكون.
أو بالأحرى، ليس حقًا مَن تكون، ولكن هذا الرقم العشوائي الكبير
بحيث إذا كان الخادم يتذكر إلى مَن ينتمي هذا الرقم،
فيمكنه معرفة صاحب الحساب ليقوم بإظهاره لاحقًا.
لذا لجعل الأمر محدّد أكثر، إذا سحبتُ بالفعل بعض أمثلة HTTP
التي ألقينا نظرة عليها في الماضي، دعونا نفكر في ذلك في السياق.
إذن من المحتمل أن معظمكم هنا قد استخدموا Gmail في مرحلة ما.
وتقومون بتسجيل الدخول بشكل عام عبر صفحة مثل هذه.
لذلك قد يكون حدوث ذلك أمرًا نادرًا لأنه لا يُطلب منكم في
كثير من الأحيان تسجيل الدخول إلى البريد الإلكتروني بسبب-- مفاجأة، مفاجأة-- وجود ملفات تعريف الارتباط
من Google على جهاز الكمبيوتر الخاص بكم.
ولكن دعونا نرى من أين تأتي تلك.
إذن عندما تقومون بطلب Google أو gmail.com، قد ترسلون، في ظرف افتراضي،
إذا جاز التعبير، من جهاز Mac أو الكمبيوتر الشخصي لديكم إلى الخادم، رسالة كهذه.
لمَن لم يرى هذا من قبل، هذا
ما يرسله متصفحك بالفعل إلى الخادم من أجل
طلب صفحة رئيسية من gmail.com.
الآن، سأقوم بتبسيط ذلك قليلاً
لوجود مجموعة من عمليات إعادة التوجيه--
تتضمن برتوكولات HTTP 302 و301 وهذا ليس أمرًا مثيرًا للاهتمام اليوم.
لذلك دعونا نفترض أن Gmail يستجيب على الفور.
عادة، ما يستجيب Gmail بهذا، يقول 200 حسنًا.
ها هي صفحة تسجيل الدخول.
وها هي صفحة ويب بتنسيق نص/html.
ولكن بمجرد تسجيلكم الدخول، فإن ما يقوم به Gmail الخاص بكم في الواقع
هو إرسال ذلك أيضًا.
تذكرون أننا نسمي هذه الأشياء رؤوس HTTP--
أزواج قيمة رئيسية مفصولة بنقطتين يتم إرسالها بشكل شبه سرى من المتصفح
إلى الخادم ومن الخادم إلى المتصفح.
الآن، نحن كمطوِّرين أكثر تطورًا يمكننا رؤية هذه الأمور، أليس كذلك؟
يمكنكم فتح علامة تبويب شبكة Chrome والبدء في التدقيق.
وهي ليست سرية في حد ذاتها.
فقط لا يعرف معظم الأشخاص أنها هناك.
وما يقوم به Google والشركات الأخرى هو
أنها حرفيًا تقوم بإرسال رأس تُسمى تعيين ملف تعريف الارتباط، القيمة التي منها
تلك القيمة العشوائية الكبيرة التي قررها الخادم من أجلكم.
متصفحكم، لنفتراض أنه يتحدث HTTP بشكل صحيح،
يجب أن يحفظ تلك القيمة لاحقًا في RAM، ذاكرة الوصول العشوائي لجهاز الكمبيوتر،
أو على محرك الأقراص الصلبة.
ومن ثم يجب أن ترسلوا كل نقرة أخرى تقومون بها على gmail.com،
ليس فقط رؤوس مثل هذه، ولكن يجب أن ترسلوا الرأس المقابلة--
مجرد ملف تعريف الارتباط، وليست مجموعة ملفات تعريف الارتباط، بل ملف تعريف الارتباط، وهو
عرض تقديمي لختم اليدّ هذا.
وبالتالي في كل مرة تنقرون فيها فوق صفحة على Gmail، أو Facebook،
أو أي موقع ويب تقريبًا قمتم بتسجيل الدخول فيه.
تم وضع ملفات تعريف الارتباط هذه على جهاز الكمبيوتر الخاص بكم.
الآن مؤخرًا، في كل من أوروبا وفي الولايات المتحدة،
تم تمرير القوانين التي تضغط على نحو متزايد
على الشركات التي تعمل دوليًا لتقديم
معلومات قائمة على ملفات تعريف الارتباط لكم، أليس كذلك؟
تحصلون على هذه القوائم المنبثقة الصغيرة بشكل متزايد.
وتحصلون عليها منذ سنوات في أوروبا لنقل،
هل يمكننا وضع ملفات تعريف الارتباط على جهاز الكمبيوتر؟
إذن بالنظر إلى كل هذا، ما الذي يمكن أن يحدث إذا قلتم
لا، لا توجد ملفات تعريف الارتباط على جهاز الكمبيوتر؟
الجمهور: يجب تسجيل الدخول في كل مرة.
ديفيد ج. مالان: يجب أن تقوموا بتسجيل الدخول في كل مرة، أليس كذلك؟
إذا قمتم بإزالة ميزة HTTP الأساسية هذه، سيتدهور العديد من تقسيمات
الويب، أو تجربة المستخدم بشكل ملحوظ.
الآن الجانب الآخر هو أن ملفات تعريف الارتباط يمكن استخدامها، ليس فقط للاستخدام الجيد، إذا جاز التعبير،
ولكن للاستخدام الضار أيضًا.
يتضح أنه توجد إعلانات كثيرة على الإنترنت، بالطبع.
وهذا ما يحرك العديد من الإيرادات التي تجعل كل شيء ممكن.
عادة ما تأتي هذه الإعلانات من علامات الصور في HTML الخاصة بكم أو علامات النص
أو بعض علامات HTML التي رأيناها في الفصل الدراسي.
لكنها تنتقل إلى خوادم تابعة لجهة خارجية، somewhereelse.com.
وتنشأ المشكلة بملفات تعريف الارتباط عندما يتم السماح لتلك الجهات الخارجية
بوضع ملفات تعريف الارتباط على جهاز الكمبيوتر الخاص بكم.
لأنه إذا انتقلتم إلى Google، وانتقلتم إلى Facebook،
وإلى Twitter-- مجموعة مواقع الويب.
لنفترض أن لدى جميعها بعض الوسطاء الذين يقومون بالإعلان عن خدمة والإعلان
على كل مواقع الويب هذه.
هؤلاء الوسطاء، إذا جاز التعبير، لأن
لديهم إعلاناتهم، وبالتالي، رؤوس HTTP الخاصة بهم على هذا الموقع،
وهذا الموقع، وهذا الموقع، هناك جهات خارجية كبيرة
هناك-- العديد منها تعلن عن شبكات-- تعرف كل مكان
تنتقلون إليه أيها الشباب لأنها ترى ملف تعريف الارتباط الخاص بكم الذي يظهر
من عدة مواقع أخرى مختلفة.
ولذا هنا توجد ملفات تعريف الارتباط، ليس علم الكمبيوتر، الهندسة الفذّة،
ولكنها في الحقيقة تشكل تهديدًا لخصوصية الفرد لأنه
يمكن استخدامها بسهولة للتعقب.
وبصراحة، AT&T وVerizon، كملاحظة جانبية، واجهتا المتاعب--
لا يعرف عدد كافي من الأشخاص ذلك--
قبل بضعة أعوام عندما بدأوا بشكل قسري، بضخ، رؤوس HTTP
إضافية متشابهة في جوهرها مع هذه لنقل جميع بيانات الهواتف الخلوية للأشخاص--
بذلك لا توجد أشياء يمكنكم رفضها بشكل قطعي من البداية.
لأن هذه كانت طريقة للمعلنين ولأنفسهم
ليتمكّنوا من تعقب المستخدمين.
إذن رؤوس HTTP هذه التي تقوم عليها ملفات تعريف الارتباط
قوية جدًا، ولكنها أيضًا مزعجة للغاية.
والآن فقط نبدأ برؤية، على الصعيد الاجتماعي والسياسي،
تراجع الإقبال على هذه الآلية البسيطة التي، آمل، أننا كمطوِّري علم الكمبيوتر
نفهم فقط آلياتها وبالتالي، الآثار الآن.
إذن دعونا نرى ذلك في سياق، على سبيل المثال.
دعوني أمضي قدمًا وأفتح مثالاً صغيرًا نسبيًا في CS50 IDE.
بالنسبة لمَن لم يعتادوا على ذلك، CS50 IDE هو تطبيق قائم على الويب
يمكنكم عبره كتابة برامج في السحابة،
فقط باستخدام أي متصفح على جهاز Mac أو الكمبيوتر الشخصي.
سأمضي قدمًا إلى حسابي هنا.
سأقوم بالانتقال إلى المتجر.
وسأنتقل إلى دليل القوالب
وأعرض هذا المثال هنا الذي يحتوي على بعض الملفات.
سيبدو هذا مألوفًا للطلاب في الغرفة.
Application.py هو تطبيق قائم على الويب.
ومن ثم لدينا بعض ملفات القوالب، إذا جاز التعبير.
في النافذة الطرفية الخاصة بي هنا، سأمضي قدمًا، وفقط باستخدام لوحة المفاتيح الخاصة بي،
سأنتقل إلى هذا الدليل المُسمى المتجر في source8، وهو متاح على الإنترنت.
سأمضي قدمًا وأقوم بتشغيل flask، والذي، بالنسبة لمَن لم يعتادوا الأمر،
هو الأمر الذي يمكنكم عبره بدء خادم ويب
والبدء بتشغيل تطبيق قائم على الويب.
إذن لديّ ذلك الآن، سأمضي قدمًا وأقوم بزيارة عنوان URL بالضبط هنا.
وسنرى متجر ويب بسيط نسبيًا وقبيح للغاية.
دعوني أمضي قدمًا وأقوم بالتكبير قليلاً.
ويتيح ليّ متجر الويب هذا شراء ثلاثة أشياء-- foos، وbars،
وbazes، أيًا كانت تلك.
وهذه موقع يشبه التجارة الإلكترونية البسيطة للغاية
حيث يجب أن أكتب فقط كمية foos، وbars، وbazes التي أريدها.
ومن ثم يمكنني المضي قدمًا وشراؤها.
إذن سأمضي قدمًا وأقول، أعطني foo واحدة، ماذا عن صفر bars،
واثنتين من baze.
وسأمضي قدمًا وأنقر فوق شراء.
والآن سترون عربة التسوق الخاصة بي.
ولكن إذا تابعتُ التسوق، سترون أنه
يقوم بإعادة التعيين، تمامًا كما لو كنتم تتصفحون Amazon أو أي موقع ويب آخر.
ولكن إذا كنتم تريدون التحقق من عربة التسوق مجددًا،
لاحظوا أنه تذكر ما كنتُ أبحث عنه.
وفي الواقع، أتعلمون ماذا؟
سأمضي قدمًا وأقوم بإغلاق النافذة.
عذرًا.
لقد فقدتُ الموقع بالفعل.
ولكن أتعلمون ماذا؟
إذا رجعتُ إلى عنوان URL هذا وأعدتُ فتحه، أرى واجهة المتجر.
ولكن إذا قمتُ بعرض عربة التسوق الخاصة بي، لقد تذكر حالتي.
لذلك لاحظوا الآن قوة ملفات تعريف الارتباط.
إنها لا تتذكر مَن تكون من ختم اليدّ فقط.
ولكن الآن يمكنكم تذكر أي شيء عن هذا المستخدم الذي تريدونه، أليس كذلك؟
عربة التسوق على Amazon أو أي موقع ويب هو أفضل مثال على ذلك
لأنه سيكون أمرًا فظيعًا، فظيعًا، فظيعًا بالنسبة إلى تجربة المستخدم أو UX
إذا قمتم في كل مرة بالنقر فوق الرابط، وفقدتم
محتويات عربة التسوق الخاصة بكم لأن الموقع نسي مَن تكونوا.
إذن هذه ميزة جذابة للتذكر.
وملفات تعريف الارتباط الخاصة بها التي تقوم بتنفيذ هذه الميزة أيضًا.
لأنه بشكل عام، ما يحدث باستخدام ملفات تعريف الارتباط هو ذلك.
عندما تقومون بتعيين ملف تعريف ارتباط باستخدام رأس تعيين ملف تعريف الذي
بدا مثل هذا، هناك زوج قيمة رئيسية
على اليمين والذي يمكن أن نسميه جلسة، وهو يحتوي على قيمة.
القيمة هي ختم اليدّ.
الجلسة مجرد مصطلح فني يشير إلى هذا التجريد
الذي يمكنكم التفكير فيه حقًا كعربة تسوق.
ولكن لا يجب أن تقوموا بأي شيء باستخدام التسوق الفعلي أو التجارة الإلكترونية.
إنه مجرد وعاء يمكنكم تخزين الأشياء فيه.
إذن هذا يقوم بإخبار الموقع أن قيمة الجلسة الخاصة بي، ختم اليد الخاص بي
هو 12345-- وهو رقم عشوائي كبير بالفعل.
ثم يمكن أن يقول الموقع، أتعلمون ماذا؟
سأقوم بتخزين وعاء من أجلكم.
دعونا نسميه قاموس Python، أو dict من أجلكم،
بداخله يمكنني وضع أي شيء أريده.
ولذا في الواقع، عندما تنتقلون إلى عربة تسوق كهذه،
ما الذي يقوم به الخادم بالفعل؟
حسنًا، عندما يرى ختم اليدّ الخاص بك، ويدرك أنه، أوه، أنت المستخدم 1234567.
أوه، هذا اسم المستخدم مالان.
دعوني أمضي قدمًا وأسحب القاموس، Python dict
من الذاكرة، أو حتى من ملف CSV إذا أردتم،
وأعرض لكم محتويات عربة التسوق الخاصة بكم.
وفي الوقت نفسه، شخص آخر، يقوم براين بزيارة الموقع نفسه بالضبط
ويُسجِّل الدخول فيه باستخدام حسابه.
يقوم بتقديم ختم يدّ مختلف، بشكل افتراضي.
وبالتالي يمكن أن يبحث موقع الويب عن قاموس مختلف
ويعرض لبراين محتويات مختلفة من عربة التسوق الخاصة به.
والأمر نفسه لكل شخص في هذه الغرفة.
إذن هذه الآلية البسيطة--
أعني، فكّروا في القوة.
هذه مجرد قيمة نص غبية key:value.
وبسبب كل ذلك تأتي جميع قدرات الويب الآن.
ولن نلقي نظرة بشكل تفصيلي للغاية على التعليمة البرمجية هنا،
لكن دعوني أعرض مقتطفًا واحدًا منها.
إذا انتقلتُ إلى application.py، فإن السحر الذي يجعل ذلك ممكنًا في flask
هو فقط استيراد هذه الميزة الإضافية.
ستتذكرون، من المشكلات القليلة الماضية
التي عملتم عليها، تقومون باستيراد بعض الأشياء من flask--
وتقديم قالب، وإعادة التوجيه، والطلب.
حسنًا، إذا قمتم بإضافة جلسة إلى تلك القائمة، والتي
هي تجريد التعليمة البرمجية لفكرة ختم اليدّ هذه، ما يمكنكم القيام به الآن
هو ذلك.
دعوني أقوم بالتمرير إلى الجزء الهام هنا.
ولاحظوا أنه يمكنكم تنفيذ سطور التعليمة البرمجية الآن،
وبالنسبة لمشكلة CS50 finance المقبلة، سطور تعليمة برمجية كهذه.
الجلسة هي قاموس Python، أو dict فقط.
يمكنكم فهرستها باستخدام أي كلمة--
foo، أو bar، أو baz، تمامًا كما يمكنكم ذلك باستخدام القواميس بشكل عام أكثر.
ويمكنكم تخزين أي شيء تريدونه فيها.
في حالتي، أريد تخزين رقم--
0 foos، أو 1 foo، أو 2 foos أو أيًا كان.
إذن يمكنني ببساطة التحويل إلى int، عنصر أشكال طلب
المستخدم، أيًا كان ذلك.
ولن أتطرق إلى بعض التعليمة البرمجية في الأعلى لأنها فقط
تقوم بتعيين الشيء بالكامل.
لكن السطر الجديد من التعليمة البرمجية، الميزة الجديدة
التي ستمكننا الآن من بناء شيء مثل موقع تداول الأسهم
على الويب وهو ببساطة هذا السطر هنا.
نظرًا لما يمكنكم القيام به أيضًا لتذكر أن المستخدم قام بتسجيل الدخول،
فقط امضوا قدمًا وقوموا بتخزين في هذه التي تُسمى بالجلسة،
قيمة، مثل، صحيح.
وإذا كانت القيمة صحيحة هناك، فيمكنكم استنتاج أن الشخص قام بتسجيل الدخول.
وإذا لم تكن هناك هذه القيمة في القاموس، فلم يقم بتسجيل الدخول.
ومن ثم سنقوم بإرشادكم بشكل أكبر قليلاً في مجموعة المشاكل التالية
باستخدام مقدمة CS50 Finance هذه.
وسنكتب بعض التعليمة البرمجية التي تعالج تسجيل الدخول،
وبذلك يمكنكم رؤية كيفية القيام بذلك من خلال المثال.
لكن الأمر سيكون متروكًا لكم بعد ذلك للبدء
بتذكُر الأسهم قام المستخدم باستخدام
الجلسات في الواقع للإبقاء على حقيقة قيامه بتسجيل الدخول بالفعل.
حسنًا.
إذن كان ذلك كثيرًا في مرة واحدة.
ولكن أي أسئلة حول ملفات تعريف الارتباط والميزة التي تقدمها،
هذه الأشياء التي تُسمى بالجلسات؟
أي شيء على الإطلاق؟
أجل؟
الجمهور: هل يتم حفظ الجلسة من جانب المستخدم أم الخادم؟
ديفيد ج. مالان: هل يتم حفظ الجلسة من جانب المستخدم أم الخادم؟
سؤال جيد حقًا.
ويمكن أن تكون الإجابة على حسب.
يمكنك التخزين في عميل المستخدم، على متصفحه.
وكما اقترح الرجل الفاضل هنا، أنه يمكنك من الناحية النظرية تخزين اسم المستخدم
وكلمة المرور الخاصة به حرفيًا-- ربما اقترحتُ ذلك في وقت سابق--
على جهاز الكمبيوتر الخاص به.
وهذا أمر سيء للأسباب التي ذكرناها سابقًا.
ولكن يمكنكم أيضًا تخزين محتويات عربة التسوق الخاصة به، foos، وbars،
وbazes.
هذا ليس أمرًا مزعجًا تمامًا كتخزين كلمة المرور الخاصة به.
ولكن إذا كنتم تقومون بشراء أشياء لا تريدون أن يعرف عنها الأشخاص حقًا،
فذلك يكون أمرًا مزعجًا.
لذلك ربما يمكننا فعل ما هو أفضل.
والأفضل غالبًا، هو تخزينها على الخادم.
إذن سيقوم موقع الويب المُصمم جيدًا عادة
بتخزين هذه القيمة العشوائية الكبيرة فقط، ختم اليدّ، على جهاز Mac أو الكمبيوتر الشخصي.
ومن ثم يتم تخزين جميع الأشياء المثيرة للاهتمام وربما الحساسة
في قاعدة البيانات أو في ملف CSV أو فقط في ذاكرة الوصول العشوائي للخادم أو في الذاكرة
كما في المتغير الشامل.
سؤال جيد.
أي أسئلة أخرى؟
لا.
حسنًا.
إذن هذه المشكلة قد حُلّت.
نعلم الآن أنه يمكننا تنفيذ أشكال تسجيل الدخول.
ونعلم أنه يمكننا تذكّر هؤلاء الأشخاص الذين قاموا بتسجيل الدخول.
إذن دعونا فقط نقوم بتحديد أن ذلك ممكن الآن.
ولكن على مدار الأسبوعين الماضيين، لم يكن الوصول إلى أشياء كملفات CSV،
القيم المفصولة بفاصلة، والتي
تقوم بإنشاء وهم جداول بيانات Google وExcel
وApple Numbers مثل الأعمدة والصفوف أمرًا قويًا بشكل لا يصدق.
لماذا؟
حسنًا، إنه بحث خطي إلى حد كبير عن كل شيء، أليس كذلك؟
ملف CSV هو عبارة عن مجرد صفوف وصفوف وصفوف وصفوف من البيانات.
وإذا كنتم تريدون البحث عن أي شيء في ذلك
الملف، على النحو الذي ربما كنتم تريدونه لتنفيذ الاستقصاء الخاص بكم،
كيف يمكنكم العثور عليه؟
حسنًا، تقومون بفتح الملف باستخدام Open.
ربما تستخدمون تكرار حلقي من النوع for وتقومون بتكرار كل سطر
للبحث عن بعض القيم، ومن ثم تقومون بإغلاق الملف.
هذا هو حرف O كبير من n.
وفي أسوأ الحالات، الأمر الذي يهمكم يكون في النهاية.
وهو ليس فعّالاً للغاية.
الآن، يمكنكم إلحاق الملفات بشكل فعّال للغاية.
تذكرون عندما فتحنا الملفات باستخدامعلامة اقتباس وعلامة إنهاء الاقتباس، "إ" لوضع الإلحاق.
فعلنا ذلك باستخدام مثال موجز، بدلاً من "ك" للكتابة.
حصلتم على مساعدة نظام التشغيل ووصلتم إلى الملف
في الأسفل، وهو فعّال أكثر.
ولكن لا يمكنكم إدراج الأشياء في المنتصف بفاعلية عالية.
لا يمكنكم حذف الأشياء بسهولة.
بالنسبة إلى تلك الأنواع من السيناريوهات، يجب عليكم حرفيًا، فتح الملف،
قراءة كل شيء، ثم كتابة أجزاء منه
أو إضافة شيء إليه أثناء قيامكم بالكتابة.
وهكذا أدرك الأشخاص منذ سنوات، حسنًا، هذا أمر غبي.
نحن البشر جميعًا في العالم نكتب باستمرار
تعليمة برمجية لفتح الملفات، وتغييرها، وحفظها.
لمَ لا يقوم بعض منا بعمل أفضل لتنفيذ هذه الميزة،
ثم مشاركتها مع العالم؟
وهكذا تم إنشاء قواعد البيانات، بشكل فعّال.
وهذه الأيام، هناك عدة أنواع مختلفة من قواعد البيانات--
قد تكونوا على دراية باستخدام الأدوات، برنامج تجاري مثل Oracle،
أو خادم SQL، أو Microsoft Access.
وفي العالم مفتوح المصدر، هناك Postgres وMySQL،
وSQLite وغيرها.
والعديد منها، حيث هذه الأسماء تشير إلى،
استخدام لغة خاصة تُسمى SQL، لغة الاستعلامات المركبة، وهي
آخر لغة سنقوم بتقديمها
لكم في دورة CS50 ما لم تختاروا بأنفسكم شيئًا آخر
في المشاريع النهائية.
ولكن باستخدام SQL، يمكنكم تحديد البيانات من قاعدة البيانات،
وإدراجها، وحذفها، وتحديثها.
جميع الأشياء التي يمكنكم فعلها بالتأكيد باستخدام Python وملفات CSV،
ستكون كتابة سطور تلك التعليمة البرمجية بأنفسكم أمرًا مملاً للغاية فقط.
إذن ما هو النموذج العقلي المناسب؟
هنا، أزعم، وجود قاعدة بيانات بشكل أساسي.
على سبيل المثال من المحتمل أن معظم الحاضرين في هذه الغرفة
استخدموا جداول بيانات Google، وإذا لم تفعلوا ذلك، فعلى الأرجح
Excel أو ربما أرقام Apple.
إذن هذه هي جداول البيانات.
وهي في الأساس ما يمكنكم تسميته بقاعدة بيانات ارتباطية.
ارتباطية-- تشير إلى وجود علاقات
بين البيانات المختلفة في الصفوف والأعمدة المُقرَّرة من قِبلكم
أو أيًا مَن قام بإعدادها.
وهذا هو جدول البيانات بالطبع.
ويحتوي على صفوف حيث تنتقل بياناتكم الفعلية.
والأعمدة-- وما هو جدير بالذكر بشأن الأعمدة؟
ما الذي يكون القيام به أمرًا تقليديًا باستخدام الأعمدة،
على وجه الخصوص في هذا الصف الأول؟
الجمهور: الرؤوس.
ديفيد ج. مالان: نعم، وضع بعض من قيم الرؤوس، أليس كذلك؟
يمكنكم بالتأكيد وضعها على اليسار.
إنه مجرد تفضيل بشري، على ما يبدو، للقراءة من أعلى
إلى أسفل بدلاً من اليسار على طول الطريق إلى اليمين.
إذن قمنا منذ سنوات فقط بتبنّي التقاليد حيث تمثل الأعمدة الخاصة بكم
أنواعًا مختلفة من البيانات، وتمثل الصفوف قيمًا مختلفة
لهذه الحقول أو لهذه الأعمدة، إذا جاز التعبير.
إذن إذا أردتم تخزين جدول بيانات القيم
لمجموعة من الطلاب في الصف الدراسي أو في الجامعة،
قد يكون أحد الأعمدة عبارة عن رقم معرّف، مثل معرّف هارفارد أو معرّف يال.
وقد يكون عمود آخر عبارة عن أسمائهم، وعناوين بريدهم الإلكتروني، وأرقام هواتفهم، وأعمارهم،
وما إلى ذلك.
ويمكنكم فقط وضع كل ذلك.
يمكنكم جعلها جميلة وكتابة الجزء العلوي بالخط الغامق وتنظيم الأشياء وفرزها.
لكن في مرحلة ما، لا تكون هذه هي الأداة المناسبة تمامًا.
وفي الواقع، واجهتُ ذلك الأمر في الدراسات العليا منذ
سنوات حيث كنتُ أقوم بتحليل مجموعات كبيرة من البيانات.
وكان النقر المزدوج فوق ملف CSV فقط، وفتحه في Excel،
ومعالجته فقط والإجابة على أسئلة البيانات التي كانت لديّ
أمرًا مناسبًا تمامًا.
ولكن في الماضي، كان Excel يحتوي على حد قدره 65536 صف.
هذا يبدو عددًا كبيرًا--
وهذا يمثل 2 إلى القوة 16، إذا كنتم تستدعون المرجع هناك.
وهكذا قرر البشر منذ سنوات في Microsoft، أن هذا يكفي.
وبصراحة، كان الأمر كذلك.
لأنه حتى في آلاف الصفوف، على سبيل المثال،
أصبح جهاز Mac الخاص بي غير صالح للاستخدام بسبب استخدام مساحة كبيرة من الذاكرة فقط.
لذلك كان ذلك مجرد حد غير عملي على أي حال.
ولكن في مرحلة ما، قد تريدون تخزين
65537 صفًا من البيانات أو مئات الآلاف من الصفوف أو الملايين من الصفوف
أو حتى أكثر.
أعني، هناك العديد من مواقع الويب، Google وFacebook
وغيرها التي تفعل ذلك بالتأكيد.
لا يمكنكم فقط استخدام برنامج على جهاز Mac أو الكمبيوتر الشخصي لديكم بعد الآن.
تحتاجون إلى استخدام برنامج رائع أكثر.
لكن هذا البرنامج الرائع غالبًا ما يزال يعمل بالطريقة نفسها.
لديكم ملف رئيسي واحد يُسمى جدول البيانات في عالمنا البشري.
ولكن في عالم الخوادم، قد تسمونه بقاعدة بيانات بدلاً من ذلك.
وفي حين أنه في عالمنا البشري، قد تكون
لدينا أشياء تُسمى أوراق أو جداول بيانات فردية ضمن الملف الأكبر،
في قاعدة بيانات، ستكون لديكم أشياء تُسمى جداول.
لكنها بالضبط الشيء نفسه باستخدام الصفوف والأعمدة.
وبذلك عندما نريد تخزين البيانات بالفعل،
يمكننا بالفعل تخزينها بهذه الطرق بالضبط.
إذن دعوني أمضي قدمًا وأفعل هذا.
دعوني أمضي قدمًا وأفتح جداول بيانات Google فقط
بصفتها ممثل قاعدة بيانات.
ودعوني أمضي قدمًا وأقوم بإنشاء ملف جديد هنا.
إذن جدول بيانات جديد-- وبذلك يمكننا فقط تمثيل أشياء مثل الطلاب.
وسأقوم بتسمية جدول البيانات هذا بالطلاب.
وسأقوم هنا بوضع أرقام هويتهم الشخصية وأسمائهم، وما هي
بعض الحقول الأخرى التي تحدثتُ عنها وتتبادر إلى أذهانكم؟
الجمهور: البريد الإلكتروني.
ديفيد ج. مالان: البريد الإلكتروني.
الجمهور: السكن.
ديفيد ج. مالان: كررها مرة أخرى.
الجمهور: السكن.
ديفيد ج. مالان: السكن.
جيد.
الجمهور: الرياضات والأمور التي يريدون القيام بها.
ديفيد ج. مالان: حسنًا.
إذن الرياضات التي يريدون القيام بها، بالتأكيد.
هذا جيد-- يبدو طويلاً إلى حد ما.
ماذا أيضًا؟
الجمهور: عام التخرج.
ديفيد ج. مالان: عام التخرج، العمر، حسنًا، جيد.
إذن عام التخرج، العمر، التركيز--
حسنًا، وربما يمكننا المتابعة، ويزداد الجدول اتساعًا فقط.
وهذه هي الأعمدة، إذا صح التعبير، أو الحقول في قاعدة البيانات.
وبصراحة، يمكنني تسمية ذلك إذا أردتُ حقًا أن يكون مُرتبًا هنا،
ويمكنني أن أسمي ذلك بالطلاب.
وأتعلمون ماذا؟
ربما يجب أن أسمي ذلك بالجامعة وليس بالطلاب.
لأنني قد أريد الحصول على علامة تبويب أخرى هنا سنسميها بشكل استباقي
باسم، لنقل، الكلية.
وربما يكون لدى الكلية أرقام هوية، ولديها أسماء،
ولديها أقسام على الأرجح، على سبيل المثال.
ولديها بريد إلكتروني أيضًا على الأرجح وهكذا.
إذن رقم الهاتف هو أمر آخر.
لكنني ربما أريد تجميع هذه الأنواع المختلفة من
البيانات في جداول بيانات مختلفة لأنها
مختلفة عن بعضها البعض إلى حد ما.
قد يكون هناك بعض التداخل، ولكنها تكون مميزة داخل أوراق مختلفة.
في عالم قاعدة البيانات، تقومون بالشيء نفسه بالضبط،
باستثناء أنكم تسمون كل شيء بقاعدة بيانات،
ويمكنكم تسمية هذه الأشياء بالجداول للتوضيح.
لكن الأهم من ذلك، باستخدام قاعدة بيانات حقيقية، إذا جاز التعبير،
يجب أن تكونوا استباقيين أكثر بشأن إخبار قاعدة البيانات
أي أنواع البيانات التي تريدون تخزينها.
الآن، هؤلاء الذين استخدموا جداول بيانات Google وأرقام
apple وExcel يعلمون أنه يمكنكم الانتقال إلى قائمة التنسيق أو قائمة البيانات
أو أيًا كان، ويمكنكم عرض الأشياء في أماكن نقاط عشرية مختلفة.
يمكنكم تحويل الأشياء إلى نسب مئوية.
ويمكنكم تنسيق البيانات.
ولكن لا يميل ذلك إلى أن يكون له أي تأثير وظيفي على بياناتكم.
إنه تفصيل جمالي فقط، على سبيل المثال، مدى كبر أو صغر
الأرقام التي تريدون عرضها في الأعمدة والخلايا الخاصة بكم.
ولكن باستخدام قواعد البيانات، يمكنكم في الواقع تقديم تلميحات هامة
إلى قاعدة البيانات التي ستساعد قاعدة البيانات هذه في تخزين البيانات والعثور عليها من أجلكم
بشكل أكثر كفاءة.
على سبيل المثال، هناك قائمة مُطولة من أنواع البيانات
التي لدينا حق الوصول إليها في SQL.
إذن SQL هي اللغة التي باستخدامها يمكننا الاستعلام عن قاعدة بيانات.
بصراحة، في شيء مثل جدوال بيانات Google وMicrosoft Excel،
كيف يمكنكم العثور على البيانات؟
سنقوم عادة بالضغط على Command-F أو Control-F، وستقومون بالبحث عنها.
هذا ليس أمرًا برمجيًا للغاية.
يمكنكم القيام بذلك باستخدام وحدات ماكرو وما شابه ذلك.
وسنقوم بذلك باستخدام تعليمة برمجية.
ولكن باستخدام SQL، يجب أن تتخذوا بعض القرارات أولاً.
تدعم SQL بضعة أنواع مختلفة من البيانات، على الأقل، في أحد أشكالها.
إذن يتضح أنه توجد منافسة كبيرة هناك.
SQL هي لغة عامة.
ولكن قد توصّلت شركات مختلفة ومجموعات غير ربحية مختلفة
إلى لهجاتهم الخاصة.
لذا تشبه إلى حد كبير ما قد نتحدّث عنه نحن البشر--
قد تتحدث مجموعات منا باللغة الإسبانية.
حسنًا، هناك اختلافات متنوعة باللغة الأسبانية، بخلاف
العديد، والعديد، والعديد من اللغات الأخرى.
وهكذا بالمثل، في عالم البرمجة،
نظرًا لوجود مجموعة فرعية شائعة من الكلمات في لغة إلى حد ما.
ولكن بعد ذلك ربما قد قامت شركات مختلفة وأشخاص
مختلفون بإضافة ميزاتهم الخاصة وطرحها فقط لأنهم يعتقدون
أن ذلك أفضل لحالات استخدامهم.
إذن في SQLite، وهي تقنية قاعدة البيانات التي سنستخدمها في CS50 IDE،
ويستخدم Android هذه، وهي شائعة للغاية في سياقات أخرى
أيضًا، IOS كذلك--
إنها تحتوي فقط على بعض الأنواع من البيانات.
البيانات الثنائية الكبيرة، من كل الأشياء، العدد الصحيح، والرقمي، والحقيقي، والنص.
الآن ماذا يعني ذلك؟
حسنًا، يتضح أنه يعني أشياء مختلفة باستخدام قواعد بيانات مختلفة.
في قاعدة بيانات شائعة أخرى، تُسمى Postgres أو PostgreSQL.
هذه لغة شائعة للغاية لمواقع الويب عالية الأداء.
إذن إذا كنتم تحاولون إنشاء أعمال تجارية، فأنتم
تحاولون إنشاء تطبيق يتم استخدامه من قِبل الجميع في الحرم الجامعي، بشكل عام،
ستستخدمون تقنية أفضل من SQLite، وهي، حسب التعريف،
خفيفة الوزن.
وستفعلون شيئًا مثل Postgres.
وهكذا سنقدم لكم هاتين اللهجتين على طول الطريق
لأنه تتيح كل واحدة منها لنا القيام بأشياء مختلفة
بدرجة دقة مختلفة.
إذن في SQL، دعونا نزعم، حتى على الرغم من أنه تبسيط،
أن هناك على الأقل هذه الأنواع من البيانات.
عند تحديد نوع البيانات المراد تخزينه في جدول قاعدة بياناتكم،
يجب أن تحددوا، ليس فقط ما يُسمى، على سبيل المثال بالمعرّف، والاسم، والبريد الإلكتروني،
والسكن.
يجب أن تحددوا أي نوع من البيانات هو.
إذن لدينا دائرة مفرغة إلى حد ما.
لأن آخر مرة فعلنا فيها ذلك كانت في أي لغة؟
C.
إذن تفعلون ذلك في SQL أيضًا، ولكنها لا تتصيد الأخطاء.
إنها ستحسّن الأداء في الواقع.
إذن هذه لمساعدتكم في الحصول على تلك البيانات بشكل أكثر كفاءة.
لأنه كلما عرف الخادم، وقاعدة البيانات، بياناتكم،
كان بإمكانهما العثور عليها بسرعة وبشكل أساسي.
إذن في عالم قواعد البيانات، يجب
أن تقرروا بشكل عام، ليس فقط لتخزين عدد صحيح، ولكن
int صغير من العدد الصحيح، أو int كبير.
وبشكل عام، على الأقل في معظم قواعد البيانات، قد تكون هذه وحدتي بايت.
قد تكون هذه 4 وحدات بايت.
قد تكون هذه 8 وحدات بايت.
إذن دعونا نثير إعجاب الحضور هنا.
إذا كان لديكم عدد صحيح قدره 32 وحدة بت، أو 4 وحدات بايت،
ما هو أكبر عدد صحيح يمكنكم تخزينه في قاعدة بياناتكم؟
(WHISPERS) 4 مليار.
شخص واحد من فضلكم، مثير للإعجاب.
الجمهور: 4 مليار.
ديفيد ج. مالان: 4 مليار صحيح تمامًا.
وقد تكون 4 مليار من القيم الإيجابية، أو ربما 2 مليار فقط
إذا كنتم تريدون أيضًا أن يكون لديكم 2 مليار أو ما يقارب ذلك من الأرقام السلبية أيضًا.
يستخدم int الكبير 64 وحدة بت، وهذا يُعد كبيرًا، كبيرًا جدًا فقط.
وint ضئيل أو int صغير بدلاً من ذلك--
يوجد أيضًا int صغير في بعض اللهجات-- int صغير هو وحدتا بايت فقط،
وهو يحسب في الواقع شيئًا كبيرًا كـ 65535، كما أشرتُ في وقت سابق.
إذن تحتاجون إلى اتخاذ القرار فقط.
الآن، لماذا ستختارون واحد أو الآخر، بينما يمكنكم فقط استخدام int كبير
وتخزين أرقام صغيرة وأرقام كبيرة على حد سواء؟
حسنًا، لماذا قد لا ترغبون ببساطة في جعل جميع قيم الأعداد الصحيحة
في قاعدة بياناتكم أعدادًا صحيحة كبيرة.
إنه أمر بسيط-- أعطني مساحة بالقدر الذي أريده.
الجمهور: ستستخدم الذاكرة.
ديفيد ج. مالان: أجل.
أنتم تستخدمون الذاكرة دون داعٍ، أليس كذلك؟
لماذا تستخدمون الذاكرة بقدر أكبر مما تحتاجون إليه؟
الآن، بشكل مثير للجدل-- يا إلهي، الذاكرة رخيصة جدًا هذه الأيام.
أصبحت أجهزة الكمبيوتر أكبر وأسرع.
لذا في بعض السياقات، ليست مشكلة كبيرة.
ولكن إذا كانت لديكم بيانات كثيرة، وكل صف من صفوفكم في قاعدة بيانات
أكبر بمقدار وحدتي بايت مما هو ضروري، ولديكم مليون واحد من الصفوف،
فهذه أعداد هائلة من وحدات البايت التي تهدرونها
وتلقونها.
لذلك يجب أن تفكروا قليلاً في أنواع البيانات هذه.
بالطبع، أنتم لا تريدون أن تكون صغيرة للغاية،
لأنكم، إذا استخدمتم int صغير أو ربما عددًا صحيحًا،
ولكن إذا كان العمل يسير بشكل جيد جدًا لدرجة أن لديكم أكثر من 4 مليار مستخدم أو 4 مليار من الصفوف
أو 4 مليار من قيم foo وbar وbaze التي تم بيعها،
وهذا بالتأكيد الذي يحدث ببيانات Google وFacebook في العالم،
من الأفضل أن تبدأوا باستخدام 64 وحدة بت لتمثيل قيم فريدة بدلاً من
32 فقط.
لأنه في نهاية المطاف، ستنفد منكم.
حسنًا، ماذا أيضًا؟
بالإضافة إلى القيم الصحيحة في SQL، قد ترغبون في استخدام قيم كسرية حقيقية.
هذه أرقام حقيقية تحتوي على نقاط عشرية.
هذا تمامًا مثل لغة C. إنها تُسمى بشيء مختلف قليلاً.
وبشكل مزعج، تستخدم كلمتين في هذه الحالة.
ولكن الرقم الحقيقي هو قيمة قدرها 32 وحدة بت وهي قيمة كسرية
حقيقية، مثل float في C، والدقة المزدوجة
مثل تلك المزدوجة في لغة C، وهي 64 وحدة بت.
ويتيح هذا لكم فقط الحصول على تحكم دقيق أكثر
في النقطة العشرية كما رأينا.
لأنه بالطبع، لا يمكنكم تمثيل الأرقام بشكل دقيق
بسبب عدم الدقة، كما رأينا في Python وC.
رقمي هي كلمة شاملة لمجموعة من الأشياء المتعلقة بالأرقام
وهي ليست أعدادًا صحيحة أو حقيقية بالضرورة.
قيمة صحيحة أو خاطئة، ومنطقية، التواريخ إذا كنتم تريدون
تخزينها حرفيًا، مثل، سنة، سنة، سنة، سنة، شرطة، شهر، شهر،
شرطة، يوم، يوم بتنسيق الكمبيوتر القياسي،
على الرغم من اختلاف الثقافات البشرية في كيفية كتابة ذلك.
التاريخ والوقت إذا كنتم تريدون أن يكون لديكم تاريخ ووقت بعده--
كلمة رقمي في الواقع هي حل للمشكلة.
يتضح أنه، في النهاية، بعد كل هذا الوقت،
لدينا آلية مدمجة لتخزين الأرقام بدقة.
وهذا توقيته مثالي لأنه، في CS50 Finance، عندما
تتعاملون مع النقود، إذا لم تقوموا عن طريق الخطأ
بتقريب مقدار الأموال التي يملكها شخص ما إما أقل أو
أكثر قليلاً.
ربما يوجد منكم مَن لديه تجمع على وجه الخصوص، لأنه، بالعودة إلى بعض الأفلام في الماضي،
إذا رأيتم فيلم سوبرمان 3،
فهذه هي الكيفية التي تم صنع بعض المال بها عن طريق إزالة السنتات
من أنظمة الكمبيوتر، وبشكل معتدل أكثر، Office Space.
قام Office Space بذلك أيضًا-- خدعة كبيرة في محاولة تقريب هذه السنتات.
حسنًا، إذا كنتم تستخدمون التقنية واللغة الصحيحتين، باستخدام SQL،
يمكنكم بالفعل تحديد نوع بيانات رقمي، يشبه قيمة كسرية حقيقية،
ولكنكم تحددون، بشكل أساسي، العدد الإجمالي للأرقام
التي تريدون معالجتها والعدد الذي يجب أن يكون بعد النقطة العشرية منها.
لذا من الشائع في أسواق الأسهم المالية استخدام
أربع نقاط عشرية من الدقة.
لذا ليست فقط السنتات إلى مكان العشرات والمئات،
ولكن إلى مكان الآلاف والعشرة آلاف،
يمكنكم الآن تحديد ذلك باستخدام قيمة أربعة من الدقة.
ولا داعي للقلق بشأن أخطاء هذا التقريب
التي تحدثنا عنها من قبل.
الطوابع الزمنية والوقت-- فقط كم من الوقت
قد مر منذ التاريخ والتاريخ والوقت يتوفران لكم أيضًا في SQL.
ثم أخيرًا هنا، القيم النصية--
يتضح أن لديكم خيار القيم عندما يتعلق الأمر
بتحديد عدد الأحرف التي تستخدمونها لتخزين بياناتكم.
يمكنكم استخدام char، كما هو الحال في C باستخدام مصفوفة،
يجب أن تقرروا مسبقًا لسلسلة كم عدد وحدات البايت التي ستستخدمونها.
وإذا قلتم char 8، فستحصلون على 8 وحدات بايت.
وإذا كان الاسم هو مالان، م-ا-ل-ا-ن، فأنتم تهدرون 3 وحدات بايت،
أو إذا قمنا بإنهائها، 2 من وحدات البايت تلك.
لكن تقدم SQL حلاً أعطته لنا Python أيضًا.
Varchar كما يوحي الاسم-- يتيح لكم عدد متغير من الأحرف
تحديد الحد الأعلى فقط.
لذا إذا كنتم تعرفون أنه سيُطلق على أحد الأعمدة الخاصة بكم الاسم.
وقد يكون اسم شخص ما هو م-ا-ل-ا-ن-- على سبيل المثال خمسة أحرف،
أو ربما أكثر بالتأكيد بالنسبة للأشخاص الذين لديهم ألقاب أطول وهي الأسماء الأولى،
يمكنكم قول varchar 100.
وهذا هو الحد الأعلى لمقدار طوله.
لكن ستكون قاعدة البيانات ذكية.
إذا كنتم تحتاجون فقط إلى خمسة أحرف أو 5 وحدات بايت،
فلن تهدر 95 حرفًا آخر من أجلكم.
وسيتحسن ذلك من أجلكم.
ومن ثم النص في النهاية، إذا أردتم تخزين عشرات الآلاف،
مثل فقرات أو صفحات النص، فهذه أكبر من varchar
حيث لا تريدون بالضرورة حدًا أعلى تم تحديده بصورة جيدة.
تريدون فقط جزءًا جيدًا من الذاكرة.
ولكن توجد آثار هنا.
وبسرعة فقط، يبدو أن char وvarchar ليستا تكميليتين.
يبدو أن char فقط غير ضرورية.
لماذا تضعوا أنفسكم في موقف حرج وتقولوا
أعطني 8 وحدات بايت فقط بينما يمكنكم فقط قول، أوه، أعطني
ما يصل إلى 100 وحدة بت، وهل يمكنك، كخادم قاعدة البيانات،
اكتشاف عدد وحدات البايت التي استخدمها بالفعل؟
لمَ يوجد هذان النوعان من البيانات؟
أجل؟
الجمهور: الوقت.
ديفيد ج. مالان: الوقت.
الجمهور: سيكون أطول لتشغيله.
ديفيد ج. مالان: أجل.
لذا الوقت دقيق.
قد يستغرق استخدام نوع بيانات واحد أو آخر وقتًا أطول.
كيف يمكن أن يحدث هذا؟
حسنًا، إذا كنت قد حصلتم على قيمة مثل char حيث تحددون
عددًا دقيقًا من الأحرف مثل 8.
إذا فكرتم بشأن الأعمدة في جداول بيانات Google وExcel،
فكل واحد من هذه الأعمدة، تلك الخلايا هي بالضبط نفس العرض، أليس كذلك؟
إنها 8 وحدات بايت، 8 وحدات بايت مجددًا.
وبمجرد حصولك على تعويضات ثابتة تمامًا--
هذا هو البايت 0، وهذا هو البايت 8، وهذا هو البايت 16، وهذا هو البايت 24، وهذا هو البايت 32،
وما إلى ذلك، يمكنكم إعادة تقديم القدرة
التي كانت لدينا في C باستخدام المصفوفات.
يمكنكم الوصول بشكل عشوائي لتقوموا بعمليات حسابية بسيطة جدًا- الضرب،
والجمع، والطرح، يمكنكم الانتقال إلى أي عنصر في عمود
إذا كان يستخدم نفس عدد وحدات البايت لكل خلية.
ولكن باستخدام varchar، إذا احتجتم إلى خلايا ضيقة صغيرة وخلايا واسعة،
فستحصلون على ما يُطلق عليه مصفوفة غير متناسقة حيث
أحد جانبيها، الجانب الأيسر، إذا جاز التعبير،
سوف يكون صلبًا ومستقيمًا جدًا.
لكن الجانب الآخر يختلف النوع حسب طول الكلمة في هذا العمود.
ولوجهة نظركة بشأن الوقت، سيستغرق جهاز الكمبيوتر وقتًا أكبر
للبحث في حقل varchar.
لأنه لا يمكن فقط الانتقال إلى العنصر الثالث.
يجب أن تبحثوا عنها جميعًا.
ولكن لحسن الحظ، في نهاية اليوم، لا تقوم قواعد البيانات بذلك.
انها لا تتحول فقط إلى البحث الخطي.
تتحول ملفات CSV، لأغراضنا، إلى البحث الخطي.
إن السحر والملكية الفكرية والخلطة السرية، إذا جاز التعبير،
التي تنتقل إلى قواعد البيانات--
خادم Oracle SQL، وMicrosoft Access، وPostgres، وMySQL، وSQLite،
هي التي قررها علماء الكمبيوتر الأذكياء حقًا لتنفيذ خوارزميات
وبنيات بيانات رائعة، غالباً قائمة على الشجرة--
إذا كنتم تتذكرون مناقشتنا بشأن الأشجار الثنائية
أو المحاولات على جداول علامات التجزئة وبنيات البيانات الرائعة تلك-- لقد
أعدّوا هذه الأنواع من بنيات البيانات والتصميمات
في برامج قواعد البيانات الخاصة بهم.
لقد جعلوها متاحة مجانًا أو متاحة تجاريًا.
وهكذا أصبح لدينا الآن فقط تجريد يُسمى قاعدة بيانات
يمكننا تخزين البيانات وقراءتها وتحديثها وكتابتها،
وتغييرها بسرعة فقط دون الحاجة إلى تنفيذ كل هذه الأشياء
على مستوى منخفض بأنفسنا.
ولذا هذا ما ستقدمه لنا قاعدة البيانات في النهاية.
ولكن يجب أن نمتلك حق الوصول إلى قاعدة بيانات للقيام بذلك.
ونحتاج إلى أن نقرر أولاً مساعدة
قاعدة البيانات من خلال إخبارها بما يجب تخزينه وكيفية تخزينه كنوع.
لذا لمَ لا نفعل هذا؟
دعوني أمضي قدمًا وأقوم بذلك بالضبط باستخدام بضعة أمثلة.
دعوني أمضي قدمًا وأفتح CS50 IDE مجددًا،
بيئة البرمجة القائمة على الويب الخاصة بنا.
ودعوني أنتقل إلى النافذة الطرفية.
لذلك بالنسبة لمَن لم يعتادوا الأمر، فإن النافذة الطرفية هي فقط تلك النافذة بالأبيض والأسود
أو هذه النافذة بالأبيض والأزرق حيث يمكنكم كتابة الأوامر.
بدلًا من الإشارة والنقر والنقر المزدوج فوق أشياء،
يمكنكم القيام فقط بالأشياء نصيًا في هذه النافذة.
ويتضح أنه في عالم SQLite،
يمكننا بالفعل استخدام أمر يُسمى SQLite3،
والذي يتيح لنا إنشاء قاعدة بيانات.
لذلك في عالمنا البشري، بالنسبة إلى ملفات CSV، لاحظتم كيف يمكننا، في تعليمة برمجية،
فقط إنشاء صفوف وأعمدة.
يمكنكم كتابتها حرفيًا في مربع النص.
SQLite هي تقنية قاعدة بيانات تستخدم التنسيق الثنائي، الأصفار والواحدات.
وبالتالي يجب أن تقوموا بالفعل بتخزين بياناتكم بشكل مختلف
باستخدام برنامج.
لذلك إذا كنتم تريدون إنشاء ملف يُسمى، على سبيل المثال، froshims.db،
يمكنني أن أقول حرفيًا SQLite ثلاثة froshims.db،
ومن ثم أنا في هذا البرنامج.
هذا برنامج قائم على نص يمكنني من خلاله إنشاء الصفوف والأعمدة.
وهذا، من خلال المصمم سيكون غامضًا قليلاً للحظة.
سيبدو هذا مشفرًا قليلاً.
ولكن إذا أردتُ المضي قدمًا وإنشاء جدول، مثل جدول البيانات هنا،
سأكتب حرفيًا نوع CREATE TABLE.
سأستدعي المسجَّلين هذا تمامًا كما في الأسبوع الماضي
عندما كنا ننظر في أمثلة froshims.
ويحتوي برنامج الرياضة الداخلي للطلاب الجدد
على طلاب يقومون بالتسجيل للرياضية.
ﻟذا سيكون لدي ﺟدول المسجَّلين هنا.
سأمضي قدمًا الآن وأحدّد أنني أريد
بضعة أعمدة لجدول قاعدة البيانات هذا، أحد الأعمدة أريد أن أُطلق عليه المعرّف،
وعمود ثاني أريد أن أسميه اسمًا، وثالث أريد أن أسميه سكن.
لذا سأحتفظ- عذرًا.
لم أقصد الضغط على Enter.
دعوني فقط أنظف هذا.
لذا الآن لدي ثلاثة أعمدة والمعرّف، والاسم، والسكن.
وإذا كنتُ سأضغط على Enter، من الناحية النظرية،
فيجب أن يتم إنشاء قاعدة بيانات.
لن تكون بيانية مثل جداول بيانات Google أو Excel،
ولكنها ستكون موجودة في IDE في ملف يُسمى froshims.db.
ولكن لا يمكنني فقط الضغط على Enter بعد.
لأنه يجب أن أخبر قاعدة البيانات أكثر قليلاً.
أنا أحتاج إلى إخبارها بذلك، أتعلمون ماذا؟
من المحتمل أنه يجب أن تكون قيمة المعرّف الخاص بي عددًا صحيحًا.
أتعلمون ما الأمر؟
من المحتمل أنه يجب أن يكون اسمي char، أو varchar؟
ما الذي يجب أن يتم تخزين اسم الطالب عليه؟
الجمهور: varchar.
ديفيد ج. مالان: Varchar، حسنًا؟
إذن varchar لأنها ستختلف، أليس كذلك؟
إذا أمكنكم التفكير في مجموعات من أصدقائكم،
فربما تكون لديهم أسماء قصيرة أو أسماء طويلة.
حسنًا، ما هو الحد الأعلى؟
ما هو مدى طول أطول اسم من أسماء أصدقائكم؟
الجمهور: 50.
ديفيد ج. مالان: 16؟
حسنًا.
هل يوجد أي أحد هنا اسمه، الأول والأخير، أطول من 16؟
الجمهور: إنه 50، معذرة.
ديفيد ج. مالان: أوه، 50.
معذرة.
اعتقدتُ، أنني سمعتُ 16.
لأنكم لن تتمكّنول من التسجيل في froshims
لأنه سيتم اقتطاع قاعدة البيانات.
وكملاحظة جانبية، إذا انتقلتم من قبل إلى موقع ويب وحاولتم الكتابة في حقل
شكل وتوقفت لوحة المفاتيح عن العمل
أو قمتم بكتابة كلمة طويلة أو فقرة، ومن ثم ضغطتم على Enter،
فاختفى بعض مما كتبتم، حسنًا، لأن قاعدة البيانات على الأرجح
يمكنها تخزين العديد من وحدات البايت فقط.
وبصراحة، هذا يحدث غالبًا في منتديات خدمة العملاء، أليس كذلك؟
لا يريدون حقًا أن تقوموا بالإسهاب مع فريق دعم
العملاء.
سيقومون بإخفاء طول الحقل الذي تكتبون فيه.
وسيفعلون ذلك أيضًا على قاعدة البيانات،
ولكن من المحتمل أيضًا أنهم لأسباب شخصية عملية،
لا يريدون قراءة شكوى كبيرة بهذا الحجم كذلك.
إذن 50--هل يوجد أي شخص اسمه أطول من 50 حرفًا؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: نعم، ليست أسماء عديدة.
ولكن أتعلمون ماذا؟
لدينا تقنية للإجابة عن ذلك.
أطول اسم في العالم--
وهو ذلك الرجل.
من المحتمل أن تكون موسوعة غينيس للأرقام القياسية محقة.
إذن اسمه هو بارنابي مارمادوك ألويسيوس بنغي كوبويب دارتانيان إغبرت
فيلكس غاسبر هامبرت إغناطيوس غايدن كاسبر ليروي ماكسيمليان نيدي أوبياغلو
بيبين كيليام روزنكرانز سيكستون تيدي يوبوود فيفاتما وايلاند آزيلون ياردلي
زكاري أوسنسكاي.
ومن الواضح أنه يُسمى نيك أيضًا.
لكن لا بأس.
دعوني أمضي قدمًا وأظلل ذلك.
ويمكنني عدّ ذلك يدويًا.
ولكنني متأكد من قيام شخص ما بإنشاء موقع ويب لعدّ الأحرف في سلسلة.
ها نحن ذا، lettercount.com.
حسنًا.
دعونا نمضي قدمًا ونلصق ذلك، نعدّ الأحرف، 225--
إذن لن يتم تسجيل نيك ما لم تقوموا فقط بتدعيم 16 أو 50.
يبدو أننا بحاجة إلى 225 على الأقل.
إذن في مرحلة ما، يجب أن تتخذوا قرارًا.
وبصراحة، لا يكون الأمر واضحًا دائمًا.
يجب أن تحددوا أن varchar سيكون-- آه، يمكن أن يكون 16،
يمكن أن يكون 50، يمكن أن يكون 225.
ولكن أتعلمون ماذا؟ إذا كان لديه أطفال--
إذن دعونا فقط نقوم بالتقريب قليلاً ونسميه varchar 255، بصراحة،
فقط لأنه كان تقليدًا.
إذن في وقت سابق من اليوم، كان 255 يميل إلى أن يكون الحد الأقصى من الطول
لهذا الحقل في قواعد البيانات القديمة.
وهذه تبدو مساحة كافية على الأقل للتلاعب بالأسماء على الأرجح.
ولكن يجب أن تتخذوا قرارًا تحكيميًا في مرحلة ما.
يمكننا تجاهل المشكلة بقول 1000 حرف.
ولكن إذا لم يحدث هذا مطلقًا حقًا،
وعلى الأرجح تقومون بإهدار المساحة، فعلى الأرجح لا يجب.
لأنه على الرغم من أنه الحد الأعلى، فأنتم تضحون بشيء مثل الوقت،
على الأرجح، للبحث عن ذلك الحقل إذا كنتم فقط
تقومون بإخبار قاعدة البيانات بأنها ستصبح أكبر مما ستكون
عليه بالفعل.
يجب أن تكون واضحة أكثر.
إذن ماذا عن السكن؟
يا إلهي، يجب أن نقوم بذلك مجددًا الآن.
كيف نفعل ذلك باستخدام السكن؟
ما هو المدى الأطول لسكن أو منزل في الحرم الجامعي؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: أنا، على سبيل المثال، حسنًا [INAUDIBLE]،، منزل ربما.
ولكن بصراحة، في مرحلة ما، لا يهم الأمر كثيرًا.
لكن كونه متناسقًا هو ما يهم.
إنها مسألة أسلوب.
إنها مسألة تصميم.
في مرحلة ما، لا يجب أن تتصيدوا أخطاء كل قيمة صغيرة.
ولكن ربما يجب أن تختاروا قيمة معقولة
يمكنكم تبريرها لرفيق سكن أو لزميل أو زميل تدريس.
ومن ثم لنقل هذا يبدو كافيًا دون أن يكون بشكل مفرط في الواقع.
ويوجد شيء واحد أخير سأفعله هنا هو فقط
إنهاء فكرتي بفاصلة منقوطة.
أعتذر، لقد عادت.
ولكن في نهاية نقطة بدايتي هنا، إذا لم أقم بارتكاب أي أخطاء مطبعية،
وسأمضي قدمًا وأضغط على Enter.
يبدو أن لا شيء يحدث.
وبشكل ساخر، في دورة CS50، في البرمجة، لا يحدث عادة
أي شيء جيد لأن ذلك يعني عدم حدوث أخطاء.
إذا قمتُ، في SQLite، بكتابة المخطط، يمكنني في الواقع
رؤية إرتجاع الجدول الذي قمتُ بإنشائه للتو.
ولكن الأهم من ذلك، يمكنني البدء في إدخال البيانات في هذا.
الآن لسوء الحظ، إنها ليست بيانية حتى الآن.
ولكن إذا أردتُ إدراج بيانات في هذا، يمكنني القيام بذلك.
أدرج في المسجَّلين-- حسنًا، ما الذي تريدون إدراجه؟
أريد المضي قدمًا وإدراج معرّف، واسم، وسكن.
حسنًا، بأي قيم؟
حسنًا، بهذه القيم--
سيكون المعرّف-- سيكون المُسجَّل الأول هو 1.
سيكون براين أول شخص يتم تسجيله.
وسكنه، براين أين كنت تعيش؟
براين: بالخارج في بيني بايكر.
ديفيد ج. مالان: بيني بايكر.
إذن هذا جيد.
قد يكون ذلك قريبًا من أربع مرات كذلك.
لذا سأمضي قدمًا وأقوم بذلك.
ها هو مثال على عبارة SQL.
CREATE TABLE هو فعل أو تعبير واحد يمكنك استخدامه.
INSERT INTO فعل آخر.
تقومون بتحديد اسم الجدول، وحقول الجدول، ومن ثم القيم.
والآن أقوم بالتكبير فقط لتوضيح ما هي أوامر SQL
وما هي الكلمات فقط في الواقع، التي اخترتُها، كمطوِّر.
ولكنه مجرد تقليد.
من المحتمل أن تكون هذه الكلمات المكتوبة بالأحرف الكبيرة بأحرف صغيرة في معظم السياقات أيضًا.
لكنها تساعد الأشياء، على ما أعتقد بشكل مرئي، في التمييز.
الآن سأمضي قدمًا وأقم بالإدخال.
يبدو أن لا شيء يحدث.
ربما هذا شيء جيد.
دعونا نمضي قدمًا ونقوم بتسجيل شخص آخر.
سأكون المسجَّل الثاني.
لذا ربما ديفيد من ماثيوز.
إذن ماثيوز هنا، Enter.
والآن، إذا أردتُ تحديد جميع الطلاب في قاعدة البيانات،
يمكنني المضي قدمًا وقول تحديد من--
أو أتعلمون ماذا؟
دعونا نختار كل شيء كما هو معروف في لغات كثيرة من خلال نجمة،
من المسجَّلين فاصلة منقوطة enter، ولدينا ذلك هناك.
إنها قاعدة بيانات خفيفة الوزن وبسيطة وصغيرة جدًا إلى حد ما.
ولكن هناك صفوف وأعمدة كثيرة تشبه إلى حد كبير جداول بيانات Excel
وGoogle التي ستضعها من أجلي.
لكنها تصبح أفضل من هذا.
لنفترض أنني أريد البحث في قاعدة البيانات هذه عن جميع الطلاب
المسجَّلين من ماثيوز.
ولنفترض أن الوقت يمر وأن العديد من الطلاب
يسجّلون حقًا في forshims.
يمكنني تصفية هذه البيانات في الواقع.
يمكنني أن أفعل شيئًا مثل تحديد نجمة من المسجَّلين حيث
سكن يساوي علامة اقتباس وعلامة إنهاء الاقتباس، "ماثيوز."
ولذا يمكنني تصفيتها، والضغط على Enter، والآن استرجعتُ صفًا واحدًا فقط.
وإذا بدأ عقلك في التساؤل--
مدهش، إذا كان بإمكاني تقديم Python أو JavaScript في هذا،
أتعرفون ما يمكنني فعله؟
ربما يمكنني العودة، وليس هذا وهذا الجدول القائم على ASCII، وجدول
النص هذا.
ربما يمكنني استعادة قائمة صفوف فعلية
حتى أتمكن بالفعل من القيام بشيء ما باستخدام هذه البيانات.
وهذا، في الواقع، حيث سنمضي في هذا.
لذا إذا أردتُ تحديد شخص آخر، فقد أتمكن من القيام اممم--
ربما تحديد الاسم فقط من المسجَّلين
حيث سكنه يساوي "ماثيوز."
إذا كنتُ أهتم فقط بمعرفة مَن تم تسجيله،
يمكنني القيام بذلك وتقليصه إلى بيانات أقل.
لذلك بالفعل، في هذه الأوامر القليلة فقط،
يمكنني التعبير عن دالات أكثر مما يمكنكم القيام به باستخدام ملف CSV.
للقيام بهذا وCSV، كان يجب أن تكتبوا جميع
هذه السطور من تعليمات Python البرمجية بأنفسكم.
ماذا لو انتقل براين؟
لذا، لم يعجب براين بسكن الطلاب بالفعل،
لذا سنمضي قدمًا ونستمر في تحديث المسجَّلين
وتعيين السكن يساوي-- إلى أين تريد الانتقال؟
براين: Canaday.
ديفيد ج. مالان: "Canaday" حيث--
يمكنني القيام بذلك بطرق قليلة.
ما هو حدسك؟
كيف يمكنني تحديد برين و براين فقط--
لا أريد الانتقال إلى Canaday.
كيف يمكننا نقل براين فقط؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: أجل.
ربما يمكننا أن نقول أن الاسم يساوي علامة اقتباس وعلامة إنهاء الاقتباس "براين" وEnter.
يعجبني هذا، لكن سيجد شخص ما خطأ في هذا إذا أمكنك ذلك.
الجمهور: شخصان باسم براين.
ديفبد ج. مالان: إذا كان هناك شخصان باسم يراين، سننقلهما
سننقل الثلاثة أشخاص.
لذلك ربما يكون أفضل، بصراحة، أن نقول، مم،
دعونا نقول فقط أن المعرّف يساوي 1.
الآن، بالطبع، أحتاج إلى رقم بطاقة هوية هارفرد الخاص ببراين أو أي شيء.
لكن هذا سيكون أكثر دقة.
لأن الافتراض هنا هو أن العمود الموجود في أقصى اليسار أو حقل المعرّف،
حسب التقليد البشري، يجب أن يكون فريدًا بحيث يعرّف
المساحة بشكل فريد حتى يمكننا الحصول على أكبر عدد ممكن من الأشخاص باسم براين كما نريد،
لكن لن يختلط علينا الأمر بشأنهم.
إذا مضيتُ قدمًا وضغطتُ فوق Enter الآن، فلن يحدث شيء.
ولكن إذا قمتُ بتحديد نجمة من المسجَّلين مرة أخرى، وضغطتُ فوق Enter، لاحظوا الآن،
تم نقل براين بالفعل إلى Canaday.
لذا هناك الكثير من الأشياء الأخرى.
براين، أتعرف ماذا؟
أنت لستَ جيدًا جدًا في الرياضة لقد اكتمل الفريق.
لذا سيتم حذفك من المسجَّلين حيث المعرّف يساوي 1.
والآن إذا حدّدنا نجمة من المسجَّلين، لقد تبقيتُ أنا فقط.
لكن تم نقل براين أيضًا.
لذا لدينا القدرة على إدراج وتحديد وتحديث وحذف،
وإنشاء، كل ذلك أثناء التصفية.
ونحن فقط بدأنا في سكراتش بالسطح هنا لما هو ممكن.
لأنه يتضح أنه، يمكننا تخزين الكثير من البيانات في قواعد البيانات هذه.
جميع طلابنا، جميع مَن في الكلية--
إذا كنتم شركة، يمكنكم البدء بتخزين
جميع المنتجات في قاعدة بياناتكم، جميع الطلبات،
جميع العملاء.
ولكن بمجرد أن تبدأ بالسير في هذا الطريق، حسنًا ، يا إلهي، ما هو العميل؟
لدى العملاء أسماء وأرقام الهوية وربما عناوين البريد الإلكتروني
والعناوين البريدية.
ستصبح هذه الأمور فوضوية-- أرقام هواتف،
تشبه الأعداد الصحيحة إلى حد ما، لكن ليس تمامًا.
لذلك هناك العديد من الأسئلة التي ما نزال نحتاج إلى الإجابة عليها.
ولكن يبدو أنه حان الوقت لبعض الفاكهة وبعض الكعك.
لذا لمَ لا نمضي قدمًا ونأخذ استراحة لمدة خمس دقائق، ونقوم بتشغيل بعض الموسيقى.
إذا احتاج الآباء إلى المغادرة، فلا بأس بذلك.
وسنراكم هنا بعد خمس دقائق أو عدة دقائق.
حسنًا.
حسنًا لقد عدنا.
وكنا قد توقفنا بالضبط هنا حيث نستخدم
SQLite3، الإصدار 3 من أمر SQLite، وهو
مجرد واجهة نصية للتقنية
التي يجب أن نفكر فيها على أنها SQLite.
SQLite مثير للاهتمام وخفيف الوزن بمعنى أنه ليس خادمًا،
إنه ليس برنامجًا خياليًا يجب أن تقوم بتشغيله.
إنه يخزِّن حرفيًا جميع البيانات الخاصة بك في ملف، ولكن، حسب التقليد،
ينتهي بـ .db أو ربما .sqlite.
ولكنه مجرد ملف ثنائي، أصفار وواحدات.
إنه ليس نصًا يمكنك فتحه باستخدام Excel أو شيء من هذا القبيل.
لذا إنه ليس CSV.
لذا يتم تخزينه في ملف.
هذا يعني أنك لا تحتاجون إلى خبرة خاصة
في إعداد خادم قاعدة البيانات.
لا تحتاجون إلى الذاكرة والبرامج لتشغيله على جهاز الكمبيوتر بالفعل.
يمكنكم تخزين كل شيء محليًا، ولكنكم ستدفعون الثمن.
لأنه تذكرون من مناقشاتنا السابقة، كانت الأقراص بطيئة.
وإذا كنتم تقومون بتخزين بياناتكم على القرص،
فلن تكون بنفس سرعة تخزينها في ذاكرة الوصول العشوائي فقط.
وهذا هو السبب وراء وجود تقنيات أخرى مثل Postgres وMySQL وMicrosoft Access
وخادم SQL وOracle.
تلك منتجات رائعة حيث يقوم شخص ما حرفيًا بالنقر المزدوج فوق رمز
أو تشغيل أمر يقوم بتشغيل برنامج
يظل يعمل في ذاكرة الكمبيوتر ويعطيك أداء أفضل.
ولكن بالنسبة لأغراضنا، SQLite من الناحية الموضوعية مفيد.
ولكننا سنستمر في طرح الأسئلة حول أنواع البيانات
لأن SQLite تدعم أنواع البيانات الرائجة أكثر مثل تلك الموجودة في Postgres
وخادم SQL، وMySQL، وOracle، وهذه هي الأمور المكتوبة بالأدوات الصغيرة
التي قدمناها قبل قليل.
لكن بصراحة، سيصبح هذا مملاً بسرعة.
حتى أنا نادرًا ما أتذكر بالضبط الصيغة الصحيحة عند إنشاء الجداول،
الترتيب الذي يجب أن يتم عليه كل شيء.
لذلك أميل إلى استخدام واجهة المستخدم الرسومية أو GUI بنفسي.
وهناك الكثير من الأدوات هناك.
ولكننا قمنا بإنشاء واحدة مجانية ومفتوحة المصدر CS50 IDE
التي تجعل تحرير جداول SQL الخاصة بك أسهل قليلاً.
لذا سأمضي قدمًا وأخرج من SQLite.
وسأمضي قدمًا إلى هنا.
وستلاحظون أن لدينا جميع الملفات من اليوم بما في ذلك،
الملف الأخير، froshims.db.
هذا هو الملف الذي قمتُ بإنشائه باستخدام SQLite3.
ولكن إذا قمتُ بالنقر المزدوج فوقه عند استخدام CS50 IDE،
فسيقوم بفتح برنامج يُسمى phpLiteAdmin.
يصادف أنه تتم مكتوبته بلغة أخرى تُسمى PHP،
ولا علاقة لها بقواعد البيانات، فقط اسم المنتج هنا.
لكنها أداة تستخدم جداول HTML البسيطة جدًا،
تمنحنا فقط واجهة مستخدم رسومية على نفس الدالة بالضبط.
وبشكل شخصي، أجد هذا أسهل في الاستخدام.
ومن الناحية الموضوعية، سيكون الأمر أفضل
لأنه سيعرض لنا أنواع البيانات المتاحة لجدولنا.
لذا على سبيل المثال، لاحظوا هنا-- هناك الكثير على الشاشة.
لكن الكثير من هذا مجرد تفاصيل غير مثيرة للاهتمام.
لكن لاحظوا هنا، أرى جدولاً يسمى المُسجَّلون.
ومن ثم يمكنني تصفحه.
يمكنني رؤية بنيته.
يمكنني تنفيذ SQL يدويًا عن طريق كتابتها.
يمكنني البحث عنها، إدراج.
يمكنني أن أقوم بمجموعة أشياء بها.
هذا هو السبب في أن واجهة المستخدم الرسومية هذه مناسبة فقط.
دعوني أمضي قدمًا وأضغط فوق المُسجَّلون.
وبشكل افتراضي، سترون علامات التبويب هذه الآن، تصفح، وبنية، وSQL،
ومن ثم مجموعة علامات أخرى.
ولاحظوا هنا.
سترون الصف الوحيد والمُسجَّل الوحيد الذي يبقى بالفعل.
لأنه عندما غادرنا آخر مرة، أزلنا براين بشكل قسري من الفريق.
لذا لنفترض أنني أريد المضي قدمًا وإضافة المزيد من الصفوف
فقط من أجل المناقشة.
يمكنني فقط القيام بذلك يدويًا هنا.
يمكنني الانتقال إلى هنا ويمكنني القول، لنفترض أن اللاعب الثالث
سيكون فيرونيكا.
أعتقد أنها كانت أيضًا في ماثيوز لذا يمكنني كتابة ذلك هنا.
ويمكنني فقط المضي قدمًا والنقر على إدراج.
ولكن ما هو لطيف بشأن phpLiteAdmin هو أنه لن يقوم فقط
بإدراج الصفوف من أجلكم، بل سيعرض لكم التعليمة
sQLite البرمجية التي يمكنكم القيام بها بأنفسكم.
لذا فهذا تعزيز بصري لطيف لهذا الأمر نفسه بالضبط.
وستلاحظون أنها تستخدم علامات اقتباس مزدوجة بدلاً من علامات الاقتباس الفردية الخاصة بي من قبل.
إنها قابلة للتبادل أحيانًا، لكن ليس بشكل دائم.
لذا هي طريقة رائعة فقط لتعلم كيفية القيام بذلك بالفعل
باستخدام تعليمة SQL البرمجية الصحيحة لذا لن تقوموا بتبسيطها
باستخدام واجهة المستخدم الرسومية.
ولكن أتعرفون ماذا؟
لنقم بذلك.
سأمضي قدمًا وأبدأ لأنني
أريد اتخاذ قرارات أفضل.
سأمضي قدمًا، حرفيًا، وأنقر بزر الماوس الأيمن أو أنقر بزر التحكم فوق هذا،
وأحذف froshims.db.
ودعونا بالفعل نبدأ من سكراتش.
الآن في السابق عندما قمتُ بهذا، كان بإمكاني المضي قدمًا،
في النافذة الطرفية الخاصة بي، وإنهاء SQLite3 وبعد ذلك، ما كان ذلك؟
Froshims.db وأقوم بإنشاء الملف.
في الوقت الحالي، سأمضي قدمًا فقط في الواقع وأنقر فوق
ملف يُسمى بهذا الاسم، وهو أمر بسيط
يقوم بإنشاؤه حرفيًا، لكنه لا يضع أي شيء فيه،
لذا لدي ملف فارغ.
وسترون أنه انبث مجددًا فقط على
الجانب الأيسر، وهو مفيد.
والآن يمكنني النقر بشكل مزدوج فوق هذا الإصدار منه، وهو لا يحتوي على أي شيء بعد.
وها قد عدتُ إلى phpLiteAdmin.
لكن لاحظوا أنه لا يوجد جدول في قاعدة البيانات.
لذا لنبدأ في طرح بعض الأسئلة الصعبة
بالفعل حول كيفية إنشاء البيانات في قاعدة البيانات.
لذا دعوني أمضي قدمًا وأنتقل إلى هذا الحقل هنا-- وأقوم بإنشاء
جدول جديد على قاعدة البيانات froshims.
سأمضي قدمًا وأطلق عليه المُسجَّلون مجددًا.
لكن كم عدد الحقول؟
لذا دعونا نحدّد المعرّف، والاسم، والسكن، ماذا أيضًا؟
البريد الإلكتروني سمعتُه في وقت سابق.
العمر سمعتُه في وقت سابق.
الجمهور: الرياضة التي تريد الانضمام إليها.
ديفيد ج. مالان: معذرة.
لذا الرياضة التي تريد-- عذرًا--
الرياضة التي تريد الانضمام إليها.
حسنًا. ستة حقول، ستة حقول، دعونا نكمل ذلك.
إذن، في الواقع، أتعرفون ماذا؟
سبعة حقول.
أريد أرقام الهواتف أيضًا هذه المرة.
لذا دعوني أمضي قُدمًا وأضغط فوق Go.
والآن سترون فقط طريقة GUI لطلب جميع الإجابات
على الأسئلة نفسها منكم كما كان الأمر من قبل.
وربما هذا أكثر وضوحًا.
وربما لا.
لكن لا يوجد بديل عن حفظ
ما تحتاج أن تكون عليه الأوامر بالضبط.
لذا من الأعلى إلى الأسفل، في ما يلي جميع الحقول التي أحتاج إلى اتخاذ قرار بشأنها.
بشكل ساخر، الحقول هي مجرد كلمة مرادفة للأعمدة.
ومع ذلك، يتم حاليًا وضع أعمدتي في صفوف،
ولكن هذه مجرد مشكلة في واجهة المستخدم.
لذا دعوني أمضي قدمًا وأقرر.
حسب التقليد، يكون حقلي الأول دائمًا المعرّف أو ربما يجب أن يكون كذلك.
وسنرى لماذا هذا قوي وقليل فقط.
يجب أن يكون نوع البيانات لذلك، حسب التقليد، عددًا صحيحًا،
ما لم يكن لديكم الكثير من البيانات مثل Facebook،
ومن ثم قد يكون العدد الصحيح الكبير منطقيًا أكثر.
ولكن لاحظوا أن هذه القائمة المنسدلة تعطينا في الواقع
قائمة لطيفة من الخيارات كما كان الأمر من قبل.
وسترون في النص باللون الرمادي، الفئة،
أو بمصطلحات منمقة، تقارب هذه الأنواع المختلفة في SQLite
وفي الكلمات المكتوبة بالأسود وبأحرف صغيرة،سترون
نوع البيانات الفعلي المدعوم من قِبل قواعد بيانات شائعة كبيرة مثل Postgres
التي قد ترغبون في استخدامها لمشاريعكم النهائية.
في الواقع، نحن نضع هذه الأمور بعين الاعتبار
لكي تستخدموا هذه في المشاريع النهائية في السحابة، وليس في CS50 IDE،
ولكن في الواقع للحصول على اسم المجال الخاص بكم
ووضع موقع الويب الخاص بكم، إذا قمتم بتطبيق ويب، هناك.
لذا هنا، لدينا كل الأنواع المتاحة.
وأسفل العدد الصحيح، سأمضي قدمًا وأختار حرفيًا عدد صحيح للمعرّف الخاص بي.
حسنًا.
التالي، أمضي قدمًا وأقوم بالتصغير.
دعوني أمضي قدمًا وأختار اسم طالب.
قبل أن نفعل ذلك هل قررنا بشأن char أو varchar؟
الجمهور: varchar.
ديفيد ج. مالان: حسنًا، varchar، وبأي حجم؟
الجمهور: 255.
ديفيد ج. مالان: 255.
لذا فإن واجهة المستخدم هنا تسمح لي فقط بكتابتها.
وبالتالي فإن الصيغة تختلف قليلاً لأنها GUI، ولكن 255.
لكن أتعرفون ماذا؟
كان الحقل الأخير هو السكن.
هذا أيضًا، أعتقد أننا قلنا varchar.
لذا دعوني أختار ذلك.
و255، على الرغم من أن هذا أحد الأمور الخلافية بشكل كبير قليلاً.
لستُ متأكدًا ما هو الرقم الصحيح، لذا في حالة عدم وضوح الأمر،
سأقوم فقط بتوحيد القيمة نفسها دون أن تكون مهدرة للغاية.
لكن لاحظوا أن هناك بعض الأسئلة هنا لم نحدّد إجابتها بعد.
لكن أشار تحولنا المثالي في وقت سابق إلى هذا.
يتضح أنكم، تحتاجون إلى اتخاذ بعض القرارات الأخرى
عند تصميم قاعدة بيانات.
إذا كنتم تعرفون مسبقًا أن أحد الحقول
هو الجزء الأساسي من البيانات لتحديد المستخدمين بشكل فريد،
فهذا هو ما يسمى بمفتاح أساسي--
العمود أو الحقول التي، تضمن، تحديد المستخدمين بشكل فريد.
لذا إذا كان لديكم شخصين باسم براين، فإن كل واحد منهما سيكون له معرّفه الخاص.
لذلك، هو مفتاحك الأساسي، وليس حقل الاسم براين.
لذلك سأقوم بإخبار قاعدة البيانات، هذا هو المفتاح الأساسي.
وستساعدني في تتبع هذا الطابع الفريد.
علاوة على ذلك، هذه ميزة خيالية.
قبل ذلك، كنت أقول بشكل يدوي وتعسفي جدًا
أن براين سيكون رقم 1، سأكون رقم 2، وستكون فيرونيكا رقم 3.
هذا مُمل.
على سبيل المثال، يجب أن يكون الكمبيوتر قادرًا على حل هذه المشكلة من أجلي.
لا أريد أن أفكر في ما هو رقم الفكرة.
يمكنكم زيادة الحقل تلقائيًا.
لذا، إذا قمتُ بالفعل بفحص هذا المربع، فإن SQL
ستقوم بكتابة فقط زائد-زائد، زائد-زائد حقل الفكرة في كل مرة
وسأدرج اسم جديد وسكن جديد.
لستُ مضطرًا حتى إلى أن أتحمّل عناء تحديد المعرّف بعد الآن.
الآن هناك عمود آخر هنا، ليس فارغًا،
حيث يمكنكم تحديد أن هذا العمود يجب ألا يكون فارغًا أبدًا.
وهذا أمر هام لأنه إذا كنتم تقومون بإنشاء موقع ويب يحتوي على بيانات هامة
يجب أن تكون لديكم من المستخدمين-- مثل،
لن يعمل تطبيقك بدون اسم المستخدم الخاص بالمستخدم أو كلمة المرور الخاصة به
أو عنوان بريده الإلكتروني--
يمكنكم أن تقولوا ليس فارغًا.
وستضمن قاعدة البيانات الخاصة بكم أنه لا يمكنكم حتى
إدراج صف في قاعدة البيانات هذه ما لم تعطوا قيمة لهذا الحقل.
لذا يساعدكم على حمايتكم من أنفسكم.
لأنه يمكنكم بالتأكيد تنفيذ ذلك
منطقيًا في Python أو في أي لغة.
لكن قاعدة البيانات هي تحدي نهائي أيضًا.
القيمة الافتراضية ليست منطقية بالفعل هنا.
ولكن بالنسبة لأنواع معينة من الحقول، يمكنكم قول، قاعدة البيانات،
أدرجي الوقت الحالي أو التاريخ الحالي من أجلي؟
الآن، لماذا قد تريدون ذلك؟
لماذا التاريخ والوقت بشكل افتراضي؟
لماذا قد يكون ذلك مفيدًا؟
الجمهور: متى تم إنشاء الحساب؟
ديفيد ج. مالان: عندما تم إنشاء الحساب، عندما اشتروا
foo، عندما نقلوا شريطًا-- أي عدد من الأسباب.
قد ترغبون فقط في معرفة، ما هو الوقت الآن؟
لكن لا يجب أن تكتبوا التعليمة البرمحية لذلك.
يمكن أن تجيب قاعدة البيانات على هذه الأسئلة من أجلكم.
إذن، فقط الكثير من الدالات التي حصلنا عليها، بالطبع، باستخدام ملفات CSV فقط.
إذن الاسم، هل يجب أن يكون مفتاحًا أساسيًا؟
لا.
وإلا لا يمكننا الحصول على شخصين باسم براين.
وبشكل عام، سيكون مفتاحكم الأساسي حقلًا واحدًا، على الرغم من ذلك،
يمكنك من الناحية النظرية إنشاء أعمدة مشتركة إذا كنتم تريدون ذلك.
لكن بشكل عام، سيكون عمود واحد.
هل يجب علينا زيادة براين تلقائيًا-- لذلك، على سبيل المثال، حسنًا--
مثل براين28، أو براين2، أو براين3، وما إلى ذلك؟
لا.
لا يبدو منطقيًا حقًا.
ليس فارغًا؟
من المحتمل.
أريد كل أسماء الطلاب الجدد حتى نعرف
مَن يقوم بالتسجيل للرياضة.
والسكن؟
أجل، ليس فارغًا.
لكن أوه، حالة حرجة--
هل يمكن أن يفكر أي شخص في حالة حرجة حيث من المحتمل
أن يكون السكن نوعًا ما فارغًا؟
الجمهور: خارج الحرم الجامعي.
ديفيد ج. مالان: إنهم يتنقلون، وهم خارج الحرم الجامعي--
إنهم ليسوا طلابًا كُثر.
ولكن إذا كان لديكم 1٪، 5٪ من الطلاب الذين يعيشون خارج الحرم الجامعي،
فهذا هو سؤال التصميم الآن.
وقد زرنا جميعًا على الأرجح بعض مواقع الويب
حيث لا يمكنكم ملء النموذج بالطريقة الصحيحة
لأنكم لا تلبون معاييرهم أو توقعاتهم.
وهذا فقط بسبب قرار التصميم السيئ.
لذلك دعونا نتيح له أن يكون فارغًا فقط في هذه الحالة.
الآن ماذا أيضًا؟
قلنا رقم الهاتف عندما اقترحتُ ذلك.
يا إلهي، لا يوجد نوع رقم الهاتف.
إذن ما الذي تريدون إنهائه؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: معذرة؟
الجمهور: [INAUDIBLE] varchar.
ديفيد ج. مالان: Varchar.
حسنًا.
حتى نتمكن من اختيار varchar وربما استخدام 10 أو حتى 10 أرقام في الولايات المتحدة،
على الأقل، على الرغم من، ربما، على سبيل المثال، 12 باستخدام علامات التجزئة، أو 13 باستخدام الأقواس،
أو--
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: ما هذا؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: أسمع همهمة.
معذرة.
الجمهور: int صغير.
ديفيد ج. مالان: int صغير ومعاملته فقط
كرقم، ربما يمكن أن ينجح هذا أيضًا.
بديل آخر؟
أي شيء آخر؟
الجمهور: [INAUDIBLE] الدقة.
ديفيد ج. مالان: الدقة-- لذا رقم محدد.
الجمهور: [INAUDIBLE] تأكد من حصولك على الرقم الصحيح.
ديفيد مالان: جيد.
لذا ليس حدسًا سيئًا.
ولكن يتضح أنه باستخدام نوع البيانات الرقمية، حيث تحدّدون معيارًا
كما أطلقنا عليه-- العدد الإجمالي للأرقام في الدقة--
والذي يُقصد به عمومًا قيم النقاط العائمة--
أي الأرقام الحقيقية ذات النقاط العشرية.
لأنه على الرغم من أنكم تحددون حدًا أقصى،
فأنتم لا تحتاجون إلى تلك الأرقام الكثيرة.
إنه مجرد حد أقصى.
أجل؟
الجمهور: أعتقد أن إعطائه--
سيكون القيام بنوع من chars تصميمًا سيئًا لأنه
يمكنكم إدخال قيم غير رقمية بعد ذلك.
ديفيد ج. مالان: أجل.
يمكننا أن نجد الخطأ، أعتقد أنه، في هاتين الفكرتين، على الرغم من أن
كلا الفكرتين معقولتان.
إذا سمحتم باستخدام char أو varchar، يمكنني كتابة
على سبيل المثال foo أو bar أو baz وليس رقمًا.
لذلك ربما يجب أن نكتب int.
ولكن هل يمكن أن يفكر أي شخص في مثال مضاد
لمَ لا يجب أن تستخدموا عددًا صحيحًا؟
الجمهور: لقد حصل على طول متغير له، أليس كذلك؟
لذا ستحصل على أي رقم--
ديفيد ج. مالان: طول المتغير.
لكن إذا قمنا بالفعل بإجراء العملية الحسابية، ربما 65،
ربما-- توجد وحدات بايت كافية هناك.
يمكننا استخدام int كبير، وهذا يعطينا رقم هاتف طويل حقًا.
لذا ربما يكون هناك حد أقصى معقول.
أجل؟
الجمهور: دعنا نقل [INAUDIBLE] بين [INAUDIBLE] عدد صحيح.
ديفيد ج. مالان: الشُرط والأقواس.
يجب أن نقرر، هل نريد دعم ذلك؟
وبصراحة، ربما نعيش جميعًا في الولايات المتحدة الآن، معظمنا
هنا.
ولكن عند إجراء مكالمة محلية في بعض المناطق، على سبيل المثال، تكتبون 0 أولاً.
وقد يكتب بعض الأشخاص 0 كرقمهم.
ولكن ما الذي سيحدث إذا كتبتم 0 في حقل عدد صحيح؟
الجمهور: ستتجاهله.
ديفيد ج. مالان: ستقومون بتجاهله.
لذا الآن توجد هذه الحالة الحرجة.
إذن اللعنة.
على سبيل المثال، من الواضح أنه لا توجد طريقة لحل هذه المشكلة.
إذن ما هو الأفضل؟
يجب أن نتوصل إلى حل وسط وأن نقبل فقط
أنه يجب حل هذا باستخدام تعليمة برمجية.
الجمهور: Varchar.
ديفيد ج. مالان: Varchar؟
حسنًا.
إذن varchars أو char.
حسنًا.
إذن ربما دعونا نعمل على تبسيط المشكلة.
لا يمكن لأي شخص خارج الولايات المتحدة أن ينضم إلى رياضة داخلية جديدة.
هذا يُبسّط الأمر.
لأنه إذا كنا ندعم فقط أرقام الهواتف في الولايات المتحدة، يمكننا الآن أن نقول 10 أرقام.
وإذا قلنا ذلك، أتعرفون ماذا؟
لا تهمني الشُرط أو الأقواس.
يمكنني استخدام تعليمة برمجية أو JavaScript أو Python، للتخلص من الصيغة.
ويمكنني فقط تخزين 10 أرقام.
ربما char 10 كافية--
3 لرمز المنطقة، ثم باقي الرقم، سبعة أرقام جميعها
فيه.
لكن قد تجدون خطأ في هذا أيضًا.
ونحن بالفعل نعزل الطلاب الدوليين في الحرم الجامعي.
لكن مجددًا، هذه مجرد قرارات تصميم غير واضحة.
ولذا نحن هنا، في نهاية الفصل الدراسي.
ليست لدينا دائمًا إجابات جيدة.
ولن يتفق الأشخاص المنطقيون بشأن ذلك.
لكن دعوني أبسط الافتراضات ونستخدم فقط الأرقام الأمريكية، 10 أرقام،
وثقوا بأنني سأستخدم التعليمة البرمجية في Python أو أي لغة أخرى
للتخلص من الصيغة، وعلامات الترقيم وأي شيء
كالأقواس والشُرط.
وسأتأكد من أن الشخص لم يكتب أي حرف من الأحرف الأبجدية.
يمكنني القيام بذلك في التعليمة البرمجية.
وأنتم تعلمون أنه يمكننا فعل ذلك حتى في JavaScript عندما يقدم الشخص شكلاً.
دعونا ننتقل إلى النهاية، الرياضة، ماذا كانت الرياضة--
الجمهور: الرياضة التي يريدون القيام بها.
ديفيد ج. مالان: الرياضة التي قد يريدون القيام بها.
إذن هذا مثال جيد، لا يجب أن تكون لديكم مسافات
في اسم الحقل، لذا التقليد سيكون الرياضة_هم_ حقًا أو ربما
أو دعونا نطلق عليها فقط الرياضة في هذه الحالة.
سنعود إلى ذلك.
أعتقد أن لدينا فكرتان أخرتان.
رقم الهاتف.
الجمهور: البريد الإلكتروني.
ديفيد ج. مالان: البريد الإلكتروني.
جسنًا.
البريد الإلكتروني فكرة جيدة.
ما الذي يجب أن يكون عليه ذلك؟
لا يوجد نوع بريد إلكتروني، لسوء الحظ، على الرغم من وجود
hTML، نوع مدخل للبريد الإلكتروني.
الجمهور: Varchar.
ديفيد ج. مالان: ما هذا؟
الجمهور: Varchar.
ديفيد ج. مالان: حسنًا، أشعر أننا ربما بحاجة إلى varchar هنا.
ولكنه هنا، غير واضح قليلاً، ما هو أطول عنوان بريد إلكتروني في العالم؟
ربما عنوان بريد نيك الإلكتروني؟
إذن لا أعرف.
ولكن دعونا نختار حدًا أعلى معقولاً يمكننا ربما أن نعتاد
عليه كمجموعة.
ولنرى-- أي شيء آخر هنا؟
لا؟
حسنًا.
هل كان هناك حقلاً إضافيًا آخر؟
الجمهور: عام التخرج.
ديفيد ج. مالان: أوه، التخرج-- أوه، العمر.
لنأخذ العمر.
إذن العمر-- أخيرًا، شيء بسيط.
ما الذي تريدون أن يكون عليه هذا؟
الجمهور: int صغير.
ديفيد ج. مالان: int صغير، حسنًا.
لن ندعم الأشخاص الذين تزيد أعمارهم عن 65535 عامًا.
على الرغم من ذلك هل يرغب شخص ما في إيجاد خطأ في هذه الفكرة؟
يمكنني القول، لا توجد إجابة واحدة صحيحة لأي من هذه الأسئلة.
الجمهور: تحتاج إلى شهر.
ديفيد ج. مالان: شهر--
أوه، على حسب.
هل نريد شهرًا؟
الجمهور: أجل.
قد نحتاج إلى [INAUDIBLE].
الجمهور: --ثم تحتاج إلى التاريخ، السنة.
ديفيد ج. مالان: إذن أنتم تفترضون أننا نريد تاريخ الميلاد.
أعتقد أنني أطلقتُ عليه العمر.
إذن ربما هذه هي المشكلة.
على سبيل المثال، إذا كان العمر، فسيكون int الصغير جيد.
على سبيل المثال، يمكن أن يكون عمرك 0 سنة أو 65000 سنة.
لدينا نطاق جيد.
الجمهور: يدور كل شيء حول العمر، تاريخ الميلاد.
ديفيد ج. مالان: إذا كان العمر، فأعتقد أننا على ما يرام.
لكنني أعتقد أنك تشير إلى نقطة جيدة، وهي ربما لماذا نريد
تخزين تاريخ الميلاد وليس العمر؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: أجل.
يتغير هذا الشيء دائمًا، بخلاف ذلك، أليس كذلك؟
على سبيل المثال، سأضطر إلى تحديث قاعدة بياناتي غدًا ومن ثم
في اليوم التالي، ناهيك عن كل ساعة أو كل دقيقة فقط
لأن أعمار المستخدمين تتغير.
يبدو هذا سخيفًا.
دعوني، بدلاً من ذلك، أحدّد قيمة--
لتقوم بشيء مثل تاريخ الميلاد.
تاريخ الميلاد-- ربما يحدد شيئًا غير int.
لكن دعونا بالفعل نستخدم حقل التاريخ.
يمكننا تخزين الوقت إذا كنا مهتمين حقًا بالوقت الذي
ولدوا فيه في يوم معين.
ولكن هنا، يمكنني أن أقول أن التاريخ سيكون أفضل قليلاً، لأنني أعرف الآن
في Python وJavaScript وحتى C، يمكنني أن أقوم بالقليل من العمليات الحسابية.
وإذا كنتُ أعرف أنهم ولدوا في هذا اليوم والشهر والسنة،
حسنًا، سأطرح ذلك فقط من اليوم والشهر والسنة الحاليين
وأكتشف كم هو عمرهم بالأيام أو السنوات-- لذا من المحتمل أنه أفضل قرار
تصميم هناك.
لكن يجب أن نوحد الشكل.
لا يمكننا السماح فقط لأشخاص من الولايات المتحدة وأوروبا وآسيا
اختيار أشكالهم الخاصة جميعًا.
تقوم SQL بتوحيد هذا-- سنة، سنة، سنة، سنة شرطة
شهر، شهر شرطة يوم، يوم.
وهذه هي قيمة وجود هذه الأنواع من البيانات مجددًا.
حسنًا.
إذن ماذا عن الرياضة-- آخر حقل؟
الجمهور: Varchar.
ديفيد ج. مالان: Varchar، حسنًا.
ما هو أطول عدد من الكلمات في الرياضة؟
الجمهور: لم أقل قد تريد القيام بها، لذا يمكن الوقوف هناك،
لكن ربما يجعل 255 الأمر منطقيًا أكثر.
ديفيد ج. مالان: ربما ما لم يكونوا رياضيين جدًا.
أجل.
هنا أيضًا لا أعلم.
ولكن فقط من أجل تقديم الاحتمالات،
عندما تعتقدون أن الشخص قد يكون إيضاحيًا قليلاً
ويكتب في الواقع فقرة عن جميع الألعاب الرياضية التي ينضم إليها
أو أي شيء أو حتى أكبر من فقرة، يكون النص أكبر.
الرياضة، ربما هذه ليست كلمة مقنعة.
وسأغيرها مجددًا إلى varchar.
ولكن إذا كتب شخص ما مقالاً في كليته
عن التطبيق المشترك، أو إذا كنتم
تطلبون من أشخاص لصق سيرهم الذاتية، أو ما شابه ذلك، فقد ترغبون في استخدام النص.
لأنه ليس لدي أي فكرة عن عدد الكلمات التي سيحصل عليها شخص ما.
يتيح لكم النص تخزين المزيد من البيانات.
لكنه يخزنها بشكل مختلف قليلاً.
إنه يميل إلى تخزينها ليس في العمود، ولكن باستخدام المؤشرات.
إذا كنتم تتذكرون منذ بضعة أسابيع، فإنه يستخدم المعادل
لذلك لتخزينها هناك، ويستغرق الوصول إليها وقتًا أطول قليلاً.
لذا مجددًا، هناك فقط مقايضة هنا.
إذن يمكننا القيام بإنشاء varchar 255--
يجعلني متوترًا قليلاً.
لذلك سأنتقل إلى قيمة مشتركة أخرى.
1024، إنها قوة 2، ولكن لا توجد إجابة واحدة صحيحة هنا.
لكن قرارات التصميم غير الواضحة هذه التي يجب أن نتخذها.
إذا لم ارتكب أي أخطاء هنا، فسأمضي
قدمًا وأنقر فوق Create، وأوه--
تم إنشاء جدول.
يمكنكم الآن رؤية جميع البيانات التي تم إنشاؤها هناك.
وها هي ذا، إذا عدتُ إلى froshims، وعدتُ إلى جدول المسجَّلين،
لا يمكنني تصفح ذلك فقط-- حيث لا يوجد أي شيء هناك حتى الآن.
يمكنني النظر في البنية ورؤية جميع تلك القيم نفسها
وتحرير بعضها مثل إعادة التسمية.
لكن لا يمكنكم تشويهها بالكامل.
ربما يجب أن تبدأوا من جديد إذا قمتم بإجراء تغييرات كثيرة جدًا.
حسنًا.
هل توجد أي أسئلة حول هذا؟
أجل؟
الجمهور: لماذا تستخدم 1024 بدلاً من 1023؟
ديفيد ج. مالان: أو، لماذا أستخدم 1024 بدلاً من 1023.
عادة، عند اختيار-- أوه، التقليد.
لا يمكنني تبرير هذا.
255 كان الحد الأقصى لأنني أعتقد أن إحدى وحدات البايت كانت محفوظة لقيمة ما،
من الناحية التاريخية.
لكن هذا ليس صحيحًا بالفعل.
تم رفع هذا الحد، وليس هناك سبب وجيه.
الجمهور: كان يمكنك استخدام 255.
ديفيد ج. مالان: هذه الأيام، أجل.
منذ سنوات، 255 كان حد فعلي.
وهكذا تم تبنيه.
الآن، لا أعلم.
لقد اخترتُ فقط قوة 2 في كثير من الأحيان.
وبعد ذلك، سيكون الانتقال إلى 2048، و4096، وما إلى ذلك، ليس فقط.
أجل؟
الحمهور: ما الفرق بين varchar وchar؟
ديفيد ج. مالان: Varchar--
ما الفرق بين varchar وchar؟
تستخدم Char عددًا ثابتًا من وحدات البايت بغض النظر عن عددها الذي تستخدمونه،
وميزتها هي الأعمدة الخاصة بكم، من الناحية النظرية،
وهي مستقيمة تمامًا على الحافة اليسرى، والحافة اليمنى، مما يعني
أنه يمكنكم الوصول بشكل عشوائي لأن كل خلية هي عدد ثابت
من وحدات البايت من الباقي.
تستخدم Varchar مصفوفة رثة، كما يطلق عليها،
حيث يكون جانب واحد، الجانب الأيمن أقصر أو أطول في خلايا مختلفة.
لذا لا يوجد سوى الحد الأقصى للطول على كل من هذه الخلايا.
ولكن البحث عنه قد يكون أبطأ كنتيجة لذلك
لأنه لا يمكنكم الانتقال من خلية إلى خلية.
يجب أن تتبعوا أطوال تلك الأشياء.
هذه مقايضة.
أجل؟
الجمهور: إذا كنتَ [INAUDIBLE] التعليم، فكيف يمكنك إضافته؟
ديفيد ج. مالان: أوه، إذا أردتُ إضافة حقل تعليم الآن وتعديل
الجدول--
إذا أدركتم بعد فوات الأوان، أوه، على سبيل المثال، أنا بحاجة إلى إضافة شيء إلى هذا،
في أداة واجهة المستخدم الرسومية، يمكننا إضافة حقل واحد في نهاية الجدول،
حرفيًا.
لذا لنقم بذلك.
دعوني أمضي قدمًا وأضغط على Go.
سأطالب بشكل متشابه، ولكن أصغر.
يمكنني المضي قدمًا وكتابة شيء مثل التعليم.
دعوني أقترح هذا varchar، ربما 255،
على الرغم من أنه يمكننا أن نخوض هذا النقاش أيضًا.
سأمضي قدمًا وأقول أضف حقولاً.
والآن لاحظوا أنه تم تغيير الجدول بنجاح.
في الواقع، لأي سبب من الأسباب، إنه لا يعرض لي
التعليمة البرمجية لهذا الأمر المعين.
ولكن هناك حرفيًا أمر ALTER في SQL
الذي يتيح لكم تغييره.
وإذا عدتُ إلى البنية الآن، سترى أن هناك
عمودًا آخر يُسمى التعليم يظهر بشكل ساخر
هنا كصف.
أجل؟
الجمهور: هل يُعد ترتيب الأعمدة أمرًا مهمًا؟
ديفيد ج. مالان: سؤال جيد.
هل يُعد ترتيب الأعمدة أمرًا مهمًا؟
بشكل أساسي، لا يهم.
حسب التقليد، عادة ما تضعون المعرّف أولاً.
وبعد ذلك، سأقوم، بشكل شخصي، حسب التصميم، بوضع أهم الحقول التالية
مثل الاسم الذي يبدو أنه هو الاختيار الصحيح،
وربما يبدو أن البريد الإلكتروني هو الاختيار الصحيح، لقد فكرتُ في الأمر
في وقت متأخر قليلاً هذه المرة.
ليس من السهل إعادة ترتيب الأشياء في SQLite، ولكن يمكنكم ذلك في قواعد البيانات الأخرى.
لذا هناك، إنه تقليد بشري بشكل أكبر.
أجل؟
الجمهور: هل هو تقليد أن تكون لديك كلمة رئيسية واحدة،
أو هل يمكن أن تكون لديك عدة كلمات رئيسية؟
ديفيد ج. مالان: سؤال جيد.
هل هو تقليد أن تكون لديك كلمة رئيسية واحدة، أو هل يمكن أن تكون لديك عدة كلمات رئيسية؟
حسب التعريف، يمكنكم فقط الحصول على كلمة واحدة.
ولكن يمكن أن تغطي هذه الكلمة الرئيسية عدة أعمدة.
لذلك لم نرَ حالة استخدام لهذا حتى الآن.
لكن هناك سيناريوهات حيث ستريدون قول،
أريد أن أضمن أن هذين العمودين معًا فريدان من نوعهما،
ولكن ليس كل واحد بمفرده فريدًا.
لكننا لن نصادف ذلك حتى الآن.
أي أسئلة أخرى، أجل؟
الجمهور: ماذا لو أضفتَ التعليم
بعد أن بدأتَ بقاعدة البيانات، وكان ذلك حقلاً ليس فارغًا؟
ديفيد ج. مالان: سؤال جيد حقًا.
ماذا لو أضفتَ التعليم بعد أن يكون لديك بالفعل بيانات حقيقية هناك،
ولكنك حددتَ أنها ليست فارغة، وهذا أمر مثير للمشاكل.
لأنه ما هي الخلفيات التعليمية للأشخاص السابقين؟
عادة، ما يمكن أن تفعله قاعدة البيانات هو إما رفضه،
أو أنها ستضع فقط "سلسلة فارغة"، علامة اقتباس وعلامة إنهاء الاقتباس.
لذلك لا يعد ذلك من الناحية الفنية فارغًا، ولكن لا يوجد أي شيء في الواقع هناك.
إنها مجرد سلسلة من طول 0.
سؤال جيد حقًا.
حسنًا.
إذن، ما الذي يمكننا فعله الآن إنه قوي قليلاً؟
حسنًا، دعوني أمضي قدمًا وأقوم بإدراج بعض البيانات بسرعة هنا.
سأحتفظ بمعظمها فارغًا.
لكن أتعرفون ماذا؟
أنا لن أزعج نفسي باستخدام المعرّف.
براين لقد عدتَ إلى الفريق.
لنمضي قدمًا وندرج براين.
دعونا نمضي قدمًا الآن إلى المسجَّلين مجددًا.
لنمضي قدمًا ونضيف فيرونيكا مجددًا.
لذا أنا أقوم بإدراج بضعة صفوف يدويًا.
ومجددًا، لاحظوا أنه يُنفِّذ كل هذا من أجلي
دون أن أزعج نفسي بكتابته.
لكن يمكنني ذلك بالفعل.
في الواقع، فقط للقياس الجيد، دعونا نقوم بشيء آخر يدويًا.
إذا قمتُ بالنقر فوق علامة تبويب SQL، فلاحظوا أنه يمكنني الحصول على اقتراح افتراضي هنا.
هذه هي الصيغة التي يمكنكم من خلالها تحديد كل شيء.
أو يمكنني فقط كتابة إدراج في المسجَّلين.
ولكن الآن، إذا أردتُ فقط إدراج اسم،
لا يجب أن أقوم بكل هذه الأعمدة.
يمكنني فقط قول امضي قدمًا وأدرج هنا، إيرين، على سبيل المثال،
فاصلة منقوطة، وقم بالتصغير وانقر فوق Go.
يبدو أن هذا ينجح.
إذا عدتُ للمتصفح الآن، فإن إيرين موجود هناك أيضًا.
لكنكم سترون الاختلاف.
كان الاستعلام الذي يتم إنشاؤه تلقائيًا بواسطة واجهة المستخدم الرسومية
يدرج بالكاد علامة اقتباس وعلامة إنهاء الاقتباس، وهو ما يُطلق عليه سلسلة فارغة من الطول 0.
قمتُ، عن طريق تجاهل ذكر تلك الأعمدة،
بإدراج فارغ عن عمد.
لذا بصراحة، أصبحت قاعدة بياناتي فوضوية قليلاً هنا.
لذلك لا تستخدموا phpLiteAdminا بشكل عام أو واجهة المستخدم الرسومية لإدراج البيانات.
قد تستخدمونه لإنشاء الجداول الخاصة بكم بطريقة مناسبة
والحصول على التطبيق بالفعل.
ولكن ستكتبون التعليمة البرمجية في النهاية.
وهذا هو الاتجاه الذي سنتبعه.
وسأمضي قدمًا وأقوم بإدراج شخص إضافي واحد.
أوه، لقد نسيتُ أنني لستُ في الفريق على الإطلاق لأننا بدأنا من جديد.
لذا دعوني أضع نفسي في الفريق، ديفيد.
ودعوني أمضي قدمًا وأنقر فوق INSERT، وأعود إلى المسجَّلين،
والآن سترون أنه يوجد أربعة منا.
تغير المعرّف الخاص بي لأنهم قاموا بالإدراج في ترتيبات مختلفة.
ولكن لاحظوا أن كل الزيادة التلقائية قد حدثت بطريقة سحرية من أجلي.
وهذا أمر مفيد لأنه لا يجب أن أفكر في ذلك.
ومَن يهتم بما هو المعرّف الخاص بي.
أنا فقط أحتاج إلى، في كثير من الحالات، في قاعدة بيانات، معرّف فريد.
لذا الآن دعونا في الواقع نكتب بعض من التعليمة البرمجية، أليس كذلك؟
حتى الآن لم نفعل أي شيء مفيد.
لقد عرضنا لكم هذه النافذة بالأبيض والأسود حيث يمكنكم
التحديد في بعض بيانات التحديث.
لكن هذا لا يحل أي مشاكل نعرفها حتى الآن.
لدينا هذه الواجهة الرسومية القائمة على الويب
والتي يمكنكم من خلالها إنشاء الجداول وإضافة البيانات، ولكن مَن يهتم؟
نحن نحاول حل المشاكل الفعلية.
وكانت المشاكل في وقت متأخر لإنشاء
البرامج التي ستحل أي عدد من المشاكل البشرية
مثل خدمة المستخدمين وعرض النتائج
أو العثور على أوجه التشابه في الوثائق.
لذا لنفترض أن المشكلة المطروحة الآن هي في الواقع لبناء شيء مثل
موقع froshims على الويب والسماح للطلاب بالتسجيل ومن ثم معرفة
مَن تم تسجيله.
حسنًا، في الماضي، كنتُ كسولاً إلى حد ما، لنقص المعرفة الفنية،
فقط إرسال بريد إلكتروني بالمسجَّلين إلى المراقب أو RA الذي كان
يدير برنامج الرياضة الداخلي.
ولكن-- بدأتُ في وقت لاحق وضعه في ملفات CSV.
لنفترض الآن، الإصدار 3، بعد 20 عامًا، أريد التخزين في قاعدة بيانات فعلية.
كيف يمكنني فعل ذلك ومن ثم رؤية النتائج؟
حسنًا، دعوني أنتقل إلى IDE مجددًا وأفتح،
على سبيل المثال، ملف جديد وسأمضي قدمًا وأطلق عليه lecture.py.
ولنفترض أنني أريد فقط أن أكتب برنامج Python بسيط يمكنكم من خلاله
تحديد البيانات من قاعدة البيانات.
إذن يتضح أنه يمكنني القيام ببضعة أشياء هنا.
أولاً وقبل كل شيء، دعوني أمضي قدمًا وأقوم، لنقل، من CS50،
لقد قمتُ سابقًا بأشياء مثل استيراد get_string وget_int
وما إلى ذلك.
يتضح أن مكتبة CS50 الخاصة بلغة Python تدعم أيضًا SQL.
وستعطينا دالة تُسمى
EXECUTE تتيح لكم تنفيذ أي أمر SQL، ولكن في تعليمة Python البرمجية.
لذا بدلاً من سحب SQLite3 بنفسي
أو الانتقال إلى واجهة المستخدم الرسومية phpLiteAdmin،
يمكنني كتابة التعليمة البرمجية التي تتحدث مباشرة إلى froshims.db،
وإزالة جميع تلك الأدوات تمامًا، وكتابة التعليمة البرمجية الآن فقط.
إذن كيف يُمكنني فعل هذا؟
سأعلن عن متغير يُسمى db لقاعدة البيانات.
إذن يمكنني تسميته بأي اسم أريده.
وسأمضي قدمًا وأطلب دالة SQL هذه.
وسأقوم بالتمرير في سلسلة تبدو غير تقليدية إلى حد ما كوسيطة،
ولكنه تقليد قياسي، لنقول ما هي
تقنية قواعد البيانات التي تريدون استخدامها؟
بعد ذلك، تقومون بكتابة نقطتين، خط مائل، خط مائل، خط مائل-- إذن إنها ثلاثة خطوط مائلة،
وليس الاثنان المعتادان في عنوان URL.
وسأقوم بتحديد froshims.db.
سيعطيني هذا الآن متغير Python الذي يُسمى
قاعدة البيانات التي تشبه مدخل، إذا صح التعبير، في ملف قاعدة البيانات هذا
الذي يمكنني إرسال SELECTs وINSERTs وDELETEs وUPDATEs إليه.
كيف يمكنني فعل هذ؟
حسنًا، إذا كنتُ في النهاية، أريد تنفيذ
المعادل من تحديد نجمة من المسجَّلين، كيف يمكنني فعل ذلك؟
حسنًا، أنا فقط محرر نص، أليس كذلك؟
هذه هي CS50 IDE.
أنا فقط أكتب نصًا.
وعلاوة على ذلك، أنا أكتب نصًا في ملف Python، وهذه ليست Python.
وبالفعل، فإن IDE تحتوي على x الأحمر الصغير هذا الذي يقول، امم-امم، لا يمكنني القيام بذلك.
ولكن يمكنني تمرير تعليمة SQL البرمجية كمدخل لدالة Python
والسماح لهذه الدالة بالتحدث إلى قاعدة البيانات.
وبالفعل، هذا ما سنحصل عليه هنا من مكتبة CS50.
سأمضي قدمًا وأفعل هذا.
أتعلمون ماذا؟
الوصول إلى قاعدة البيانات وتعليمة SQL البرمجية التالية EXECUTE،
علامة اقتباس وعلامة إنهاء الاقتباس، "التي" تغلق الأقواس.
الآن، ما هو خيار الإرجاع حسب التقليد؟
ما الذي يجب أن أعيده؟
حسنًا، في SQLite3، رأينا فقط جدولاً قائم على النص بشكل جيد
بسطور وخطوط مائلة تبدو كجدول، ولكنه كان مجرد نص.
phpLiteAdmin، رأينا بالفعل جداول HTML عندما كنتُ أتصفح قاعدة البيانات.
واقترحتُ ذلك شفهيًا قبل قليل، أتعرفون ماذا؟
إذا كنتُ سأقوم بإرجاع كل هذه البيانات في التعليمة البرمجية، فما هو نوع البيانات
الذي أريده لنفسي كـ؟
الصفوف.
أُريد صفوفًا من جدول.
اعرض لي جميع الطلاب الذين قاموا بالتسجيل.
ما هي بنية البيانات التي تبدو ملائمة في Python؟
الجمهور: القائمة.
ديفيد ج. مالان: أجل، مجرد قائمة، أليس كذلك؟
قائمة مُرتَبة من الصف الأول إلى الصف الأخير.
لذلك سنطلق على ذلك قائمة أو مصفوفة، كما كان في لغة C. لذا أتعرفون ماذا؟
سأفترض أن هذا صحيح.
وإذا قرأتُ الوثائق، فسأجد أنها صحيحة.
دالة EXCUTE في CS50، إذا قمتم بتحديدها، فستقوم بإرجاع قائمة صفوف من أجلكم.
قد تحتوي على 0 من الصفوف إذا لم تكن هناك تطابقات.
ولكن قد تحتوي على 1000 صف إذا كانت هناك تطابقات كثيرة.
سأقوم بتخزين تلك النتائج، أينما كانت، في مصفوفة الصفوف الخاصة بي.
الآن، لنفترض أنني أريد طباعة مَن قام بالتسجيل في قاعدة بياناتي
من أي موقع froshims موجود.
أفترض أن الطلاب قاموا بالتسجيل على الويب.
الآن أنا فقط مراقب أو RA أحاول في الواقع
التلاعب بالبيانات والقيام بشيء ما بها.
إذن ما الذي يمكنني فعله؟
حسنًا، بالنسبة إلى صف من الصفوف، ما الذي أريد فعله؟
دعوني فقط أمضي قدمًا وأطبع مَن تم تسجيله.
إذن مَن تم تسجيله.
حسنًا، كيف يمكنني إدخال هذا؟
حسنًا، هناك عدة طرق للقيام بذلك.
دعونا نرى.
أولاً، يمكنني استخدام صيغة العنصر النائب للطباعة.
ومن ثم أريد طباعة الصف.
ولكن ما الذي أريده من هذا الصف؟
ما هي الأعمدة في أي صف في قاعدة البيانات هذه؟
الجمهور: [INAUDIBLE]
ديفيد ج. مالان: معرّف واسم وسكن ورقم هاتف ورياضة.
حسنًا، يتضح أنه، سيتم تسليمها إليك كقواميس Python
أو بنيات dict.
لذا يمكنني فقط أن أقول صف علامة اقتباس وعلامة إنهاء الاقتباس، "اسم" هنا.
وسأستخدم علامة اقتباس واحدة فقط لجعل ما يحدث هنا واضحًا أكثر.
ثم أنا أحتاج إلى إجراء إصلاح واحد.
كيف يمكنني--
الجمهور: F.
ديفيد ج. مالان: --F لسلسلة التنسيق.
لذلك تبدو مشفرة قليلاً.
لكن هذه فقط أشياء Python الآن.
الشيء الوحيد الجديد هو SQL.
ولكن إذا حدّدنا أن SQL، عند استخدام دالة التنفيذ هذه،
ستقدم لكم قائمة من الصفوف، كل منها
عبارة عن قاموس بحيث يمكنكم الحصول عليه في هذا العمود أو هذا العمود--
المعرّف، أو الاسم، أو السكن--
يبدو هذا الآن تقاربًا جميلاً في هذا الأسبوع--
الآن، مع الأسبوعين الماضيين.
إذن دعوني أمضي قدمًا وأحفظ ذلك.
دعوني أمضي قدمًا وأعرض وحدة التحكم الخاصة بي، لذا أنا لدي نافذة طرفية.
ودعوني أمضي قدمًا وأقوم بتشغيل Python من lecture.py.
وفي غضون لحظات، إذا عقدتُ أصابعي،
آمل أن أرى مَن قام بالتسجيل.
مدهش.
لقد رأيت مَن تم تسجيله.
الآن يوجد سطر مخرج واحد لم أتوقعه، وهو هذا السطر فقط.
تُصبح هذه المكتبة مفيدة فقط من الناحية الموضوعية.
إنها تعرض لي كل أمر أرسلتُه إلى قاعدة البيانات.
ولكن سترون أن ذاك وذاك مُسجل.
إذن هذا مثير للاهتمام إلى حد ما.
إنه برنامج غبي إلى حد ما، أليس كذلك؟
لأن معظم المراقبين لن يقوموا باختراق
froshims باستخدام نافذة طرفية وتشغيل نصوص Python.
من المحتمل أنهم سيرغبون في القيام بذلك عبر صفحة ويب
ليروا بالفعل مَن هو مُسجل.
ولكن إذا كانت لدينا القدرة في تعليمة Python البرمجية للقيام بذلك، على سبيل المثال،
التكرار، ما الذي يمكنني فعله بدلاً من من مجرد الطباعة على الشاشة؟
ما الذي يمكنني طباعته للأسبوع الماضي ولمجموعة المشاكل السابقة؟
يمكنني طباعة HTML، أليس كذلك؟
على سبيل المثال، جميع الطلاب الذين سجلوا، يشعرون إلى حد ما
بأنها فرصة لقائمة غير مرتبة
أو قائمة مرتبة أو جدول أو أيًا كان.
يمكنكم الآن إنشاء HTML.
إذن دعوني أقوم بهذا.
دعوني أنتقل بالفعل إلى مثال قمتُ به مسبقًا.
ماذا لو مضيتُ قدمًا وفتحتُ layout.html.
ها هو تخطيط بسيط لتطبيق ويب باستخدام Flask.
بالنسبة لهؤلاء الذين ليسوا على دراية به، هذه HTML تقريبًا
بالإضافة إلى تقنية تُسمى Jinja، والتي تُعد تقنية قائمة على الويب لإنشاء
مواقع الويب بشكل ديناميكي.
من الواضح أن بنية هذه الصفحة هي ما تهمنا.
أتعلمون ما الأمر؟
أراهن أنه يمكنني القيام ببعض المنطق هناك بالضبط.
إذن دعوني أمضي قدمًا وأفعل هذا.
دعوني أمضي قدمًا وأقوم بإنشاء، لنقل، ملف جديد.
دعونا نُسمي هذا application.py.
سأمضي قدمًا، توفيرًا للوقت فقط،
وأقوم بالقليل من النسخ واللصق لأوفر القيام ببعض ضغطات المفاتيح.
إذن، ها هو تطبيق ويب بسيط للغاية.
وسيكون هذا ما أفعله.
لذا إذا انتقلتُ هنا إلى القوالب، دعوني أفتح index.html--
ودعوني أنتقل إلى هنا.
إذن خلاصة القول--
ها هو ما يقودنا إليه هذا.
ماذا لو قمتُ بدلاً من ذلك بإنشاء قائمة غير مرتبة باستخدام تعليمة برمجية من الأسبوع الماضي،
لكنني أستخدم التكرار الحلقي من النوع for هنا داخل تطبيق الويب الخاص بي
في الواقع بدلاً من استخدام ملف lecture.py بسيط فقط.
حسنًا، تذكرون أنه يمكنني أن أفعل شيء كهذا.
يمكنني أن أحصل على تكرار Jinja حلقي.
إذن يمكنني قول شيء كهذا for row في rows.
ومن ثم، هنا بالأسفل، يمكنني القول بشكل استباقي شيء
مثل andfor، وهذه كانت الصيغة الغريبة الخاصة بنا من الأسبوع الماضي.
ومن ثم، هنا، يمكنني فقط إنشاء عنصر قائمة.
ومن ثم، إذا أردتُ عرض مَن قام بالتسجيل، فما الذي أكتبه هنا؟
شيء بين هذه الأقواس المتعرجة إذا كان كل صف يُمثل مُسجَّل؟
الجمهور: صف.
دايفيد مالان: اسم الصف مُسجل.
يمكنني القيام بشيء من هذا القبيل.
إذن الفكرة نفسها، أقوم بتغليفه فقط بالقليل من HTML.
الآن دعوني أنتقل إلى ملف application.py لأنني
سأضطر إلى ملء بعض الفراغات.
ودعوني أرى، كيف يمكنني القيام بذلك؟
حسنًا، في النهاية، أريد إرجاع نتيجة تقديم
قالب يُسمى index.html.
للذين ليسوا على دراية بهذا، هذا فقط سطر من التعليمة البرمجية
يقول اعرض هذا الملف للمستخدم.
لكنني لا أريد فقط أن أعرض له الملف كما هو.
لكن دعونا على الأقل نحصل على هذا الإعداد.
أنا قلق من أنه قد لا يعمل بعد لأنني أحتاج إلى الحصول على البيانات الفعلية.
إذن كيف يمكنني الحصول على جميع الصفوف للمُسجَّلين لديّ؟
حسنًا، يمكنني أن أفعل هذا صفوف يساوي db.execute.
ويمكنني أن أمضي قدمًا وأكتب تحديد نجمة من المُسجَّلين وأقوم بتخزين ذلك هناك.
يُطلق على هذا الملف froshims.db والذي قمتُ بإنشائه مُسبقًا.
وكل الأشياء الأخرى هي أشياء Flask فقط من الأسبوع الماضي.
لا شيء آخر جديد.
الشيء الوحيد الجديد هو هذا السطر هنا،
وهذا السطر هنا، والآن هذا السطر هنا حيث
أستخدم SQL داخل استدعاء Python عبر تمريره
كوسيطة إلى دالة تُسمى EXECUTE.
كيف يمكنني تمرير الصفوف إلى index.html؟
الجمهور: [INAUDIBLE]
دايفيد ج. مالان: نعم، على سبيل المثال صفوف تساوي صفوف وهو التقليد الذي تبنّيناه.
يمكنكم تسميه أي شيء تريدونه، x يساوي y،
ولكن هذا مباشر أكثر قليلاً.
إذن هذا ما سنقوله، مرحبًا، قاعدة البيانات، قومي بإحضار جميع الصفوف من المُسجَّلين لديّ،
ثم تقديم قالب index.html، والتمرير في هذه الصفوف.
والآن، إذا حبستُ أنفاسى وقمتُ بتشغيل flask، لا توجد أخطاء في الصيغة.
إذا مضيتُ قدمًا وقمتُ بزيارة هذا هنا وفتحتُ--
اللعنة-- علامة التبويب، أرى خطأ داخلي في الخادم.
إذن لحظة نتعلم منها، يا قوم.
دعونا نعود إلى نافذة المتصفح تلك هنا ونرى ما حدث.
حسنًا.
خطأ في صيغة القالب-- إذن خطأ غبي جدًا.
يبدو أنني توقعتُ قوسًا مربعًا بدلاً من قوس متعرج.
هذا قابل للإصلاح.
دعوني أنتقل إلى index.html.
وأوه، لم أُنهي فكرتي.
إذن هذا بعض من إحباطات البرمجة لهؤلاء
الذين يرون هذا لأول مرة.
دعوني أقوم بحفظ ذلك.
دعوني أعود إلى المتصفح هنا، وسنقوم فقط بإعادة التحميل.
يا إلهي، ها هي ذا، الآن لديّ صفحة ويب
التي يمكنكم عبرها رؤية مَن قام بالتسجيل.
لكن أتعرفون ماذا؟
يمكننا جعل هذا قوي أكثر.
تذكرون أننا كنا نعبث باستخدام HTTP لبعض الوقت.
وإذا كان هذا هو عنوان URL الذي أصل إليه، فتذكّروا
أننا عبثنا بإعادة تنفيذ دالة البحث.
حسنًا، ماذا لو كنتُ أريد دعم بحث كهذا حتى يمكنني فقط زيارة q
يساوي ومن ثم البحث عن أسماء أشخاص، لنقل، براين
ورؤية عدد المُسجَّلين باسم براين.
هل يمكننا إضافة دعم لشيء مثل هذا؟
حسنًا، ربما.
دعوني أعود إلى IDE، إلى application.py.
ودعوني أمضي قدمًا وأقول شيئًا من هذا القبيل.
q يساوي request.args احصل على q لرؤية ما إذا كان أي شيء موجود هناك بالفعل.
ثم دعوني أمضي قدمًا وأفعل هذا.
تحديد نجمة من المُسجَّلين حيث--
دعوني أرى-- q حيث ماذا؟
الاسم يساوي q.
لكنني أحتاج إلى عنصر نائب.
إذن ربما يجب أن أفعل هذا.
وبمجرد أن أفعل هذا، أحتاج إلى ماذا؟
F لسلسلة تنسيق.
إذن يمكنني فقط إنشاء، وبشكل سريع، أمر SQL
الذي يمكنه إدخال قيمة q بين تلك الأقواس
المتعرجة للتعبير عن منطق تحديد جميع
المُسجَّلين حيث أسماؤهم تساوي براين أو فيرونيكا
أو اسم أي شخص كتبتُه.
دعوني أعود إلى المتصفح هنا.
دعوني أنتقل وأفعل شيء من هذا القبيل الآن.
علامة استفهام q يساوي براين-- سأعقد أصابعي كما فعلتُ من قبل.
اللعنة.
حسنًا.
وما هو الخطأ الذي قمتُ به هنا؟
ما هو الخطأ الذي قمتُ به هنا؟
هذا دقيق.
ونحن نرى هذا لأول مرة.
يعتقد أنه يوجد عمود يُسمى براين.
لكن لماذا يعتقد ذلك؟
حسنًا، ما قمتُ به بفعالية تم إرساله في هذا.
لا تُعد براين كلمة رئيسية في SQL.
ولأنها سلسلة فعلية التي أقوم بمقارنتها معها،
ما أحتاج فعله في الواقع هو هذا.
وإلا ستعتقد SQLite أنه كاسم العمود أو شيء ما
قمتُ بإنشائه مُسبقًا إذن يجب أن نصلح ذلك.
لكن لا مشكلة.
يمكنني وضع علامات الاقتباس هناك.
ولكن على الأرجح يجب أن أضع q هناك في علامات الاقتباس.
دعوني أحفظ هذا، وأعود إلى المتصفح، وأُعيد تحميله.
وها نحن ذا.
الآن لدينا وظيفة لبراين.
إذن باستخدام هذه الكتلة البنائية الأساسية، ما الذي قمنا به؟
حسنًا، في SQL، لدينا العديد من الأوامر تحت تصرفنا--
إنشاء جدول، والذي يصبح بصراحة أمرًا مملاً عند كتابته.
أنا أميل إلى استخدام phpLiteAdmin وتوصيتها فقط لإنشاء الجدول الخاص بكم
وجعله يعمل.
ولكن يمكنكم بالتأكيد يدويًا، باستخدام SQLite3 أو phpLiteAdmin، إدراج معلومات،
أو تحديثها، أو حذفها، أو تحديدها
بمجرد أن تكون بالفعل في قاعدة البيانات.
وذلك قوي جدًا.
ولكن بمجرد القيام بذلك، يمكنكم الآن استخدام الصيغة الجديدة نفسها، تلك اللغة الجديدة
SQL، وتمريرها كمدخل باستخدام "سلسلة" إلى دالة EXECUTE لدينا،
والآن ابدأوا بسحب أي بيانات تريدونها من قاعدة بياناتكم.
الأسبوع الماضي، باستخدام ملفات CSV، إذا أردتم القيام بذلك،
كان يجب أن تفتحوا ملف CSV، واستخدام تكرار حلقي من النوع for للتكراره،
والبحث في كل عمود وصف عن بياناتكم، ثم تمريرها.
وهذا جيد.
هذا صحيح.
هذا ليس سيئًا.
لكنه مُمل.
وتعيدون اختراع العجلة مرارًا وتكرارًا.
ولا يوجد تصفية مُدمجة فيه كما توجد في SQL نفسها.
إذن لديكم الآن أداة أكثر تطورًا
في مجموعة الأدوات الخاصة بكم، إذا جاز التعبير يمكنكم عبرها حل ذلك النوع نفسه من المشاكل.
إذن أي أسئلة على هذه التقنية؟
حسنًا.
حسنًا، دعونا ننظر إلى قاعدة بيانات أكبر ونرى إلى أين قد يؤدي بنا هذا الأمر؟
إذن إذا انتقلتم إلى موقع الدورة على الويب، فسترون
قاعدة بيانات أكبر وهي في الواقع متاحة في تنسيقات متعددة، SQLite،
والتي سنراها في غضون لحظات، ولكن أيضًا جداول بيانات Google.
لأنها بصراحة، جيدة أكثر عند النظر
في الصفوف والأعمدة في GUI مما هو عليه، بالضرورة،
بالملف نفسه.
إذن يُصادف أن هذا نموذج قاعدة بيانات مجانية ومفتوحة المصدر.
على سبيل المثال، أخذ شخص ما، منذ سنوات، قاعدة بيانات iTunes الفعلية الخاصة به--
كل الموسيقى التي اشتراها، كتب برنامجًا
لتحليل تنسيق ملف Apple في iTunes
واستخرج جميع البيانات التي يبدو أنه تم تخزينها عنه،
أعتقد كانت القصة، وجعلها فقط متاحة للعامة كنموذج
قاعدة بيانات للطلاب والمدرسين لاستخدامها فقط لمعالجة البيانات.
لكن الأمر المثير للاهتمام هو أن قاعدة البيانات هذه
تُثبت بعض المبادئ الأخرى التي لم نتطرق إليها حقًا.
على سبيل المثال، إذا كنتُ سأخزِّن، مرارًا وتكرارًا،
جميع هؤلاء الطلاب الذين يسجّلون في froshims،
ما الذي ترونه في حقول معينة؟
حسنًا، كنتُ كسولاً قليلاً، ولم أحمّل نفسي عناء كتابة سكن الجميع.
لكن لنفترض أن المئات من الطلاب قد سجّلوا في froshims.
سيكون الكثير منهم من ماثيوز، بعضهم من بيني بايكر،
بعضهم من Candaday، وبعضهم من ويلد، ومجموعات المباني الأخرى في الحرم الجامعي.
يصبح الأمر سخيفًا قليلاً عندما
ترون ماثيوز، ماثيوز، ماثيوز،
متكررة كثيرًا-- مثل، 100 مرة أو أكثر.
إذا كان هناك 1600 طالب جديد، يوجد الكثير من الأطفال في ماثيوز.
ذلك عدد كبير من وحدات البايت ليتم تخزينه م-ا-ث-ي-و--
لا أعرف.
هذا ليس مهمًا.
لا يهم كيف تتم تهجئتها.
ذلك عدد كبير من وحدات البايت ليتم تخزينه بالفعل في قاعدة بياناتكم مرارًا
وتكرارًا.
يبدو الأمر كما لو يجب أن تكون هناك فرصة
لفصل القواسم المشتركة.
وما يفعله الأشخاص عبر قواعد البيانات هو، بمجرد التعرف على نمط
متكرر للبيانات، والسلاسل نفسها مرارًا وتكرارًا، أتعلمون ماذا؟
بدلاً من استخدام-- الآن التهجئة تهم--
م-ا-ث-ي-و-ز-- وهي ست وحدات بايت.
أو ب-ي-ن-ي-ب-ا-ي-ك-ر، وهي تسع وحدات، لدينا الكثير من وحدات البايت المستخدمة
مرارًا وتكرارًا لتخزين جميع هذه المساكن.
أتعلمون ماذا؟
ما هو أفضل من 9 أو 6 وحدات بايت؟
دعونا فقط نستخدم int، أو دعونا نستخدم int صغير--
وحدتين أو 4 وحدات بايت لتمثيل المساكن.
إذن بدلاً من تخزين ماثيوز، دعونا فقط نُخزِّن الرقم 8.
وبدلاً من بيني بايكر، دعونا نُخزِّن الرقم 9 فقط، وبالتالي،
باستخدام بعض وحدات البايت، ولكن عدد أقل، وبالتالي،
حفظ وحدات بايت على المدى الطويل.
إذن ما تُثبته قاعدة البيانات هذه هو بالضبط ذلك المبدأ.
بالتأكيد، عندما يتعلق الأمر بالموسيقى، حيث يمتلك الفنانون ألبومات عديدة
ولديهم أغاني كثيرة، من المحتمل أن
تخزين اسم الألبوم في قاعدة بيانات موسيقية أمرًا سخيفًا قليلاً
مرارًا وتكرارًا لـ 10 أو 12
أو 20 أغنية أو مقطع موسيقي في هذا الألبوم الخاص.
إذن ما فعله هذا الشخص هو هذا.
لاحظوا هنا، لدينا مجموعة كاملة من الأوراق.
أو فيما يتعلق بقاعدة البيانات، ستكون هذه جداول.
ولاحظوا أن هذه الجداول تحتوي على أعمدة.
ولاحظوا أن هذه الأعمدة هي معرّف الألبوم،
في جدول الألبوم، ومعرّف الألبوم وعنوانه.
ولكن لاحظوا ما فعله بذكاء شديد باستخدام هذا الحقل، معرّف الفنان.
يمتلك الفنانون أو المطربون الكثير من الأغاني بأسمائهم، في نهاية المطاف.
ولذا قام بتعيين قيمة فريدة لكل أغانيهم،
أو قامت Apple بذلك، في iTunes بشكل غير ظاهر.
إذن، كيف أعرف ما هو اسم هذا الفنان؟
كيف يمكنكم اكتشاف ذلك؟
هذا ليس مثيرًا للاهتمام بالنسبة لنا كبشر لنعرف، أوه، الرقم الثاني من معرّف الفنان.
هذا فقط-- ما هذا؟
الجمهور: أنت بحاجة إلى جدول آخر للفنانين.
ديفيد ج. مالان: أجل.
نحتاج إلى جدول آخر للفنانين، وهذا صحيح هنا.
إذن دعوني أمضي قدمًا وأنظر هناك.
إذن إذا أردتُ أن أرى-- دعونا نرى، "Let there be rock،" الفنان رقم 1.
دعونا ننتقل إلى جدول الفنانين.
ويتضح أن، فرقة AC/DC، هي مَن قامت بغناء تلك الأغنية.
الآن أضفنا خطوة هنا، والتي ربما تستغرق بعض الوقت.
لكنها ستوفر مساحة على المدى الطويل إذا لم أُخزِّن أسماء
طويلة للفنانين-- على الرغم من أن AC/DC ليس اسمًا طويلاً جدًا--
مرارًا وتكرارًا.
الآن، أيهما أفضل؟
حسنًا، إنها مقايضة.
هل اعتدتم بشكل كبير علي إهدار المساحة وتخزين كل شيء معًا؟
أو أنكم تفضلون توفير مساحة وفقط قضاء وقت أكثر قليلاً
في جمع البيانات مرة أخرى معًا؟
ولكن سيصبح الأمر بالفعل مُزعجًا إذا، الآن،
إذا أردتُ إنشاء موقع ويب يعرض لي أسماء الأغاني
التي لديّ في قاعدة بيانات ومطربي تلك الأغاني،
ناهيك عن الألبومات، والأكثر من ذلك، عناوين المقاطع الموسيقية، وهكذا.
يبدو أن هناك ثلاثة استعلامات، أليس كذلك؟
على سبيل المثال تحديد الألبوم، تحديد الفنان، تحديد العناوين--
لكن لا.
باستخدام SQL، يمكنكم طي ذلك تمامًا.
لأنه لاحظوا، في هذا الجدول هنا، الفنان،
يوجد عمود يُسمى معرّف الفنان وهو عبارة عن أرقام.
ولاحظوا، إذا كنتم تتخيلون هذا، فإن
هذا يشبه أطراف الأصابع هنا-- دعونا نقترح بشكل مجازي--
تمثيل معرّف الفنان.
إذا انتقلتُ إلى الألبوم الآن، لاحظوا أن لدينا معرّف الألبوم وعنوانه،
لكن لدينا أيضًا معرّف الفنان.
إذن إذا تخيلتم هذين الجدولين يتقاسمان هذا العمود المشترك، ماذا لو
قمنا بتجميعهما معًا هكذا، ليتطابق أحدهما
على اليسار، والآخر على اليمين، وبالتالي نعيد بناء
كل المعلومات وتكرارها حسب
الحاجة لكي أجد الألبوم والعنوان والفنان فقط.
حسنًا، كيف يمكنني التعبير عن ذلك؟
حسنًا، دعوني أمضي قدمًا في CS50 IDE حيث لديّ نسخة من هذا الملف.
دعوني أغلق كل علامات التبويب من وقت سابق وأنتقل إلى هذا الملف الذي يُسمى lecture.db.
وفي lecture.db، في phpLiteAdmin، سنرى جميع هذه الجداول نفسها.
وقمتُ حرفيًا فقط باستيرادها إلى SQLite.
سترون جميع هذه الجداول نفسها.
يمكننا تصفح الألبوم تمامًا كما فعلنا من قبل.
ونرى فقط تنسيقًا مختلفًا للبيانات نفسها.
إنها البيانات نفسها من جدول بيانات Google،
وهو سهل الاستخدام بشكل كبير فقط.
ودعوني أمضي قدمًا وأفعل هذا.
يمكنني، بالطبع، تحدي نجمة من الألبوم
حيث معرّف الفنان لدينا يساوي 1 للحصول على جميع ألبومات AC/DC.
وبالفعل، هنا، لديّ اثنتان.
لدى هؤلاء أغنية For those about to rock، We salute you، وLet there be rock.
لديهم اثنتان.
ولكن لاحظوا، تحتوي الصفوف التي حصلت عليها فقط على أي معلومات؟
عنوان معرّف الألبوم، ومعرّف الفنان.
أعرف فقط، كشخص، أن أوه، هذه هي ألبومات AC/DC.
ولكن ماذا لو أردتُ أن أعرف، حسنًا، أرى أن معرّف الفنان هو 1.
إذن حسنًا، جيد، دعوني أفتح علامة تبويب أخرى هنا.
والآن دعوني أقوم بتحديد نجمة من الفنان حيث معرّف الفنان يساوي 1.
ولذا إذا أردتُ أن أعرف شيئًا عن ذلك الفنان-- دعوني أمضي قدمًا
وأقوم بالتصغير، وأنقر فوق Go، وحسنًا-- الآن لقد حصلتُ على AC/DC.
حسنًا، هذا رائع.
الآن لديّ نتيجتان، مجموعتان من الصفوف.
هذا غبي.
الآن، سأقوم بإنشاء ذلك لنفسي فقط عن طريق الحصول على قيمتي إرجاع.
يمكنني استدعاء db EXECUTE مرتين.
لكن هناك طريقة أفضل.
يتضح أن، SQL تتيح لكم جمع الجداول فقط باستخدام SQL نفسها.
إذن سأمضي قدمًا وأفعل هذا.
سأمضي قدمًا وأقوم بتحديد نجمة من الألبوم،
ولكن أيضًا من الفنان حيث Album.Artistid--
دعوني أنتقل إلى اليمين--
يساوي Artist.Artistid.
إذن لاحظوا أنني أقول حدّد كل شيء من جدولين،
ولكن فقط قم بذلك حيث تحتوي جداول الألبوم، عمود معرّف
الفنان على نفس القيمة كجداول الفنان أي عمود معرّف الفنان.
هذا يشبه تجميع أصابعي معًا، بشكل مجازي،
للبحث عن هذا العمود المشترك.
إذا مضيتُ قدمًا، ونقرتُ فوق Go، رائع، انظروا ما الذي قمتُ بإنشائه للتو.
إنها معلومات كثيرة، ولكن لديّ معرّف الألبوم وعنوانه،
لديّ معرّف الفنانين، ولكن أيضًا لديّ اسم ذلك الفنان.
إذن إذا كنتم الآن تتذكرون تعليمة Python البرمجية،
أوه، يمكنني الآن الحصول على مجموعة كاملة من الصفوف التي تحتوي
كل شيء يهمني مرة واحدة.
لا أحتاج إلى إجراء عمليتي تحديد استعلامات.
يمكنني تجميع هذه الجداول بهذه الطريقة.
وأنا أستخدم كلمة تجميع بشكل متعمد.
يتضح أنه توجد طريقة أخرى للتعبير عن هذا الشيء نفسه.
بدلاً من استخدام صيغة الفاصلة تلك، قد ترون هذا أيضًا،
تحديد نجمة من الفنان تجميع الألبوم على Artist.Artistid يساوي--
دعوني أقوم بالتمرير--
Album.Artistid.
سيكون لهذا التأثير نفسه بالضبط،
ولكن قد تجدون فقط أنه يبدو بديهيًا أكثر لكم.
حدّد كل شيء من نتيجة تجميع هذين الجدولين.
كيف تريدون تجميعهما؟
حسنًا، قم بتجميعهما على هذا يساوي ذلك--
مجرد طريقة أخرى للتعبير عن الفكرة نفسها.
وإذا قمتُ بالنقر فوق Go، فسأحصل على المعلومات نفسها.
إذن في نهاية المطاف، باستخدام التجميعات هل لدينا القدرة على إعادة تجميع البيانات.
إذن من ناحية، هذا فقط تدريب جيد على تطبيع قاعدة البيانات لديكم.
تحديد الأعمدة التي تحتوي على الكثير جدًا من التكرارات، وفقط
تخزين تلك المعلومات مرة واحدة.
على سبيل المثال، CS50 Finance، إذا كنتم تدعمون
العديد من المستخدمين المختلفين، في كل مرة يشتري فيها مالان أو براين أو فيرونيكا سهمًا،
يبدو الأمر سخيفًا قليلاً لتخزين مالان
أو براين أو فيرونيكا بجانب Netflix، الرمز، وعدد الأسهم
التي اشتراها أحدنا.
لأن مالان، مالان، مالان، مالان
ستظهر جميعها في قاعدة البيانات.
وماذا لو قمتُ بتغيير اسم المستخدم لديّ أو اسمي أو أصبح أي شخص متزوج
وبالتالي، يتغير؟
مثلاًَ، لماذا تخلقون تلك الفوضى لأنفسكم؟
بدلاً من ذلك، أعطوني أنا وبراين وفيرونيكا وكل شخص آخر معرّفًا فريدًا.
وعندما يقومون بشراء شيء ما، فقط قوموا بتخزين معرّف المستخدم أو العميل الخاص بهم
أو أيًا كانت الطريقة التي تريدون أن تفكروا بها في ذلك، تمامًا مثل معرّف الألبوم ومعرّف الفنان.
ولذا تطبيع قاعدة البيانات يدور حول إيجاد تلك القواسم المشتركة
ونقل البيانات إلى الجدول الخاص بها.
وإذا كنتم تهتمون بإعادة تجميعها، فقط استخدموا
SQL لإعادة إنشاء عرض البيانات ذلك، إذا جاز التعبير.
إذن ما الذي يمكننا فعله هنا أيضًا؟
يتضح أن في SQL يوجد، ليس فقط مفاتيح أساسية،
ولكن توجد أيضًا قيود فريدة في بعض قواعد البيانات حيث يمكنكم تحديد،
هذا ليس المفتاح الأساسي الخاص بي، ولكنني أريده أن يكون فريدًا.
يمكنكم أن تحددوا أنه يجب فهرسة شيء ما.
إذن يتّضح أنه، إذا كنتم فقط تعرفون أنه يوجد حقل في قاعدة بياناتكم
التي تريدون أن تتمكّنوا من البحث فيه بفعالية كبيرة،
يُمكنكم فهرستها مُسبقًا.
وسترون أو ستتمكّنوا من فعل ذلك إذا أردتم ذلك في المشاريع النهائية
أو حتى لمجموعة المشاكل القادمة إذا كنتم تريدون ذلك.
لكن ما يُمكّنه هذا هو استعلامات مثل هذه.
إذا أردتُ أن أمضي قدمًا وأبحث عن، على سبيل المثال--
ما الذي سيكون مثالاً جيدًا؟
الروك.
أنا مهتم بموسيقى الروك.
لذا إذا أردتُ أن أنتقل إلى علامة تبويب SQL هنا.
يمكنني قول شيء من هذا القبيل.
تحديد نجمة من الألبوم حيث الاسم لا يساوي،
ولكن حيث الاسم مثل ومن ثم سأقول "موسيقى الروك."
ولكن إذا أردتُ أن يأتي أي عدد من الأحرف قبل هذه الكلمة،
يمكنني استخدام علامة النسبة المئوية.
وإذا جاء أي عدد من الأحرف بعدها، يمكنني استخدام علامة النسبة المئوية.
هذه مثل أحرف البدل.
في معظم اللغات، ستستخدمون نجمة.
في SQL، تستخدمون علامات النسبة المئوية.
لكنها تعني الأمر نفسه.
وإذا مضيتُ قدمًا وقلتُ go، الآن أعود--
أوه، أحصل على، حصلتُ على المحاضرة الخاطئة، الألبوم، أوه، أعتقد أن ما أردتُه هو عنوان.
دعوني أحاول ذلك مجددًا، عذرًا--
حيث العنوان مثل "الروك"--
دعوني أمضي قدمًا وأنقر فوق Go.
وها هي ذا، الألبومات جميعها في قاعدة البيانات التي
تحتوي على كلمة روك.
الآن، كملاحظة جانبية، يحتوي هذا الجدول على الكثير من الألبومات.
وبصراحة، إنه صغير بما يكفي.
إنه يحتوي على مئات الصفوف، ربما بضعة آلاف من الصفوف.
لن يلاحظ أي واحد منا نحن البشر مدى بُطء البحث الخطي حقًا.
لكن إذا بدأتم بالحصول على آلاف الصفوف، أو عشرات الآلاف
من الصفوف، أو ملايين الصفوف، بدون فهرس
هذا يعني أن البحث عن شيء مثل روك سيبدأ في الأعلى
والبحث في كل حقل على طول الطريق إلى الأسفل، حرف O كبير من n.
بدلاً من ذلك إذا أخبرتم قاعدة البيانات، أعلم أنني
سأبحث في هذا العمود كثيرًا، من فضلك قم بفهرسته من أجلي،
ها هي الخلطة السرية.
SQLite، وOracle، وMicrosoft Access، وما إلى ذلك، فهم
سيقومون، باستخدام الملكية الفكرية الخاصة بهم،
بإنشاء بعض بنيات البيانات الرائعة-- أشجار، أو جداول علامة تجزئة،
أو أي شيء في الذاكرة، وتخزين البيانات لكم بطريقة غير مرئية في هذا التنسيق
إذن، عندما تطرحون سؤالاً على سبيل المثال، اعرض لي جميع الألبومات مثل روك،
يمكنها أن تجيب بشكل أسرع بكثير من الإجابة الخطية.
وهذا أيضًا هو ما تحصلون عليه باستخدام SQL وليس باستخدام ملفات CSV.
تُعد ملفات CSV، حسب طبيعتها، خطية فقط.
إذن يمكننا فعل ما هو أفضل.
لكنكم، كمبرمجين، يجب أن تساعدوا قاعدة البيانات
وتعطوها بالفعل تلك التلميحات، ليست فقط الأنواع،
ولكن تلميحات أيضًا كهذه.
وكملاحظة جانبية، هناك أيضًا فكرة المفاتيح الخارجية
حيث، إذا أردتم حقًا قفل أشياء، فيمكنكم تحديد ذلك،
إذا رأيتم ذلك من قبل في معرّف الألبوم في جدول آخر،
إذا كانت الكلمة الرئيسية في جدول الألبومات،
حسب التعريف، في الجدول الآخر، ستتم تسميتها كلمة رئيسية خارجية.
لأنه بالفعل لا تنتمي إلى هناك، لكنها
تشير إلى عمود في مكان آخر.
إذن توجد تقنيات ومفردات كثيرة.
ونرحب بكم لتتعمقوا في الأمر أكثر.
والاحتمالات هي، أن الكثير منكم سيفعل ذلك في المشاريع النهائية،
حسب طبيعة الرغبة في ميزات معينة، من بينها، حتى
تلك التي رأيناها مثل الزيادة التلقائية وليس فارغ.
كملاحظة جانبية أيضًا، حتى SQL تحتوي على دالات.
وبالنسبة إلى علماء البيانات والإحصائيين
إنها مفيدة للغاية لتتمكّنوا فقط من القيام بعملية حسابية وتلخيص البيانات مباشرة
داخل SQL دون كتابة تعليمة Python البرمجية أو R أو أي شيء آخر.
يتم الإنشاء في SQLite وقواعد البيانات الأخرى هي
دالات مثل هذه للمتوسط، وحساب أشياء، والحصول على
الحد الأدنى، والأقصى، والمجموع، وهكذا--
تحصلون على كل هذا مجانًا باستخدام قواعد البيانات متعددة.
كل ما يتطلبه الأمر في سياق Python هو سطر كهذا.
لكن، لكن، لكن توجد بعض المشاكل.
ودعونا ننهي الأمر من خلال إلقاء نظرة على مشكلتين من المشاكل والتهديدات الأساسية التي
لا يتم تقديرها بالفعل في كثير من الأحيان.
في الواقع، علينا إصلاح ثغرة خطيرة جدًا قمتُ بتقديمها
في تعليمتي البرمجية في وقت سابق.
ولكن أولاً، ما يُسمى بشرط التعارُض.
في الاستقصاء-- أو بالأحرى، دعونا نرى--
لنفترض أننا رجعنا بالذاكرة إلى بداية الفصل الدراسي، حيث قام معظمكم
بالتسجيل على حساب GitHub للمرة الأولى.
وانتقلتم إلى github.com/signup.
بالنسبة لمَن ليسوا على دراية به، GitHub هو موقع ويب
حيث يمكنكم حفظ وتخزين برمجة التعليمة البرمجية التي قمتم بكتابتها
وتريدون التعاون مع الآخرين عليها.
واخترتم اسم مستخدم.
ودعوني أمضي قدمًا وأحاول اختيار اسم مستخدم، على سبيل المثال، jharvard
لجون هارفارد.
لاحظوا أن الموقع على الفور قال أن اسم المستخدم موجود.
حسنًا، هذا مفيد.
ومن المحتمل أنه يمكنكم تخمين كيف يتم هذا الأمر-- ربما بعض JavaScript،
باستخدام AJAX، والتحدث إلى الخادم، والحصول على الاستجابة،
وتغيير HTML أو CSS أو أيًا كانت.
قد يستغرق ربط كل ذلك معًا بعض الوقت.
لكن هذا ما يحدث على الأرجح.
إذن دعوني أُجرب اسم مستخدم طويل وعشوائي جدًا غير موجود.
مهلاً، إنه متوفر.
ولكن من المحتمل أنه ليس أمرًا جيدًا لكي أقوم ببث هذا على الإنترنت.
لأنه إذا انتظرتُ طويلاً بما فيه الكفاية، أراهن أن شخص ما يمكنه، للتسلية،
فقط التسجيل بهذا، ناهيك عن أي شخص في هذه الغرفة.
ولكنك أخبرتني للتو أنه متوفر.
جيد جدًا.
أنا متحمس جدًا.
لقد حصلتُ على اسم المستخدم الخاص بي.
دعوني أمضي قدمًا وأكتب عنوان بريدي الإلكتروني،
malan@harvard.edu، كلمة المرور الخاصة بي، 12345-- يستغرق الأمر بضع لحظات هناك.
التحقّق من حسابي وهكذا.
ثم أنقر فوق Submit.
لنفترض أنه تم إخباري، بشكل مؤقت، معذرةً، اسم المستخدم هذا موجود بالفعل.
هل يمكن أن يحدث ذلك؟
نعم، إذا حاول أحدكم أن يعبث معي الآن،
فقد تقومون بالتسجيل باسم المستخدم ذلك وتسبقوني
لذا عندما أضغط على الانضمام، أحصل على خطأ.
هذا هو تعريف شرط التعارض حيث يوجد شخصان أو مستخدمان
أو جهازا كمبيوتر أو مُؤشرا ترابط--
إذا أردنا بالفعل تذكّر مناقشتنا عن مؤشرات الترابط في سكراتش--
إنهما يحاولان القيام بالشيء نفسه في الوقت نفسه تقريبًا.
وإذا كان هذان الشيئان، مؤشرات ترابط أو أشخاص،
يتحققان من حالة المتغير، وهي طريقة رائعة لقول
هل اسم المستخدم متوفر، ويحصل كلاهما على إجابات.
لكن بعد ذلك، بعد بضعة أجزاء من الثانية لاحقًا،
يتخذون قرارًا بناءً على تلك المعلومات، توجد نافذة للوقت،
إما أجزاء من الثانية أو حتى ثواني أو دقائق،
حيث يمكن أن تتغير، بالطبع، حالة ذلك المتغير.
إذن إذا قمتم أنتم أيضًا، حرفيًا، الآن على جهاز الكمبيوتر المحمول،
بكتابة اسم المستخدم الطويل جدًا ذلك، من المحتمل أنه سيتم إخبارنا جميعًا، ضوء أخضر،
أنه متوفر.
لكن سيحصل عليه واحد منا فقط بالفعل.
وذلك بسبب شرط التعارض.
حرفيًا، قد يتعارض جميعنا في التسجيل لتلك القيمة.
و عندما يمكن للحالة أن تتغير تحدث أشياء بين ذلك.
هذا أمر سيء لأنه يجعل البيانات لديكم
مُعرضة للتغيرات عبر شخص لا تقصدونه بالضرورة.
أو إذا لم تكن قاعدة البيانات ذكية، فربما
سيكون بإمكانكم القيام بأشياء سيئة بشكل خاص.
تُعد أجهزة الصراف الآلي مثال متعارف عليه لهذا.
إذا كان لديكم خصم ضار يحاول تسجيل الدخول إلى حسابين مصرفيين في وقت واحد
أو جهازين ماديين في وقت واحد، إما عبر بطاقتين أو حسابين وجهازي
كمبيوتر محمول، يمكنكم تخيُل أنهما سيحاولان اسقتطاع، على سبيل المثال،
مئة دولار من الحساب نفسه على الفور.
لأن تخيلوا موقع الويب الخاص بالبنك تم تنفيذه بشكل سيئ.
يتحقق من رصيد حساب المستخدم الذي سجّل الدخول.
هل لديك مئة دولار؟
إذا كانت الإجابة نعم، ربما سيقول كلا موقعي الويب نعم،
يمكنك استقطاع مئة دولار.
تضغط على Enter وها هي ذا، تستقطع مئة دولار.
يحصل المستخدم عليها بطريقة ما لأنه تم نقلها إلى حساب آخر.
لكن يعتقد البنك أنه فعل ذلك مرة واحدة فقط، يستقطع 100 $،
ولكنك قد رحلت للتو ومعك 200 $ لأنك اتخذت قرار بناءً
على الإجابة نفسها في مؤشري ترابط مختلفين
أو برنامجين مختلفين أو جهازي كمبيوتر مختلفين.
إذن خلاصة القول، يمكن لهذا أن يحدث في العالم الحقيقي حتى.
كان هذا مثال قد تعلمته من المُرشد الخاص بي منذ سنوات.
لنفترض أنكم ورفقاء سكنكم لديكم ثلاجة صغيرة في السكن.
وأنكم معتادون، بالطبع، على شرب الكثير من الحليب.
وإذن نفد الحليب من الثلاجة.
وتعود إلى المسكن، أول رفيق سكن بعد المحاضرات.
وتُدرك، أوه، أنا حقًا بحاجة مشروب حليب.
وإذن تتفقد الثلاجة.
لا يوجد شيء هناك.
إذن تغلق الثلاجة، وتدخل مباشرةً، وتنتقل إلى CVS،
وتقف في الصف لشراء بعض الحليب.
في الوقت نفسه، يأتي رفيقك إلى السكن.
أيضًا، هو حقًا بحاجة مشروب من الحليب.
إذن يتحقق من حالة المتغير.
تبًا، لا يوجد حليب.
يغلق الثلاجة، ثم يذهب على سبيل المثال إلى Tommy's Convenience أو أي مكان آخر
قريب ويقف في الصف لبعض الحليب.
بالطبع، بعد ذلك يصل كلاكما للمسكن في نهاية المطاف.
والآن ما الذي يحدث؟
اللعنة، الآن لديكم ضعف كمية الحليب.
ويفسد الحليب بسرعة.
إذن الآن هذه مشكلة، مشكلة سيئة للغاية.
لديكم ضعف كمية الحليب عن التي بإمكانكم شربها.
ولكن ما هو أصل تلك المشكلة بشكل أساسي؟
الجمهور: شيء ما نفد عندك.
ديفيد ج. مالان: شيء ما نفد عندك، لكن--
الجمهور: أنت بحاجة إليه.
ديفيد ج. مالان: --أنت بحاجة إليه.
لكن لماذا انتهى بي الأمر باثنين؟
الجمهور: لا يوجد علم.
ديفيد ج. مالان: لا يوجد علم، أليس كذلك؟
لا توجد إشارة.
لا يوجد مشاركة الحالة.
كلاكما قمتما بفحص قيمة المتغير،
اتخذتما قرار بشكل مستقل بناءً عليه.
لكن تغيرت حالة ذلك المتغير لأحدكم.
لأنه عندما أتى أحدكم إلى المسكن، الشخص الذي أتى لاحقًا، اللعنة، مثلاً،
قد تم بالفعل إعادة تعبئة الحليب.
إذن كيف يمكنكم حل هذا؟
في العالم الحقيقي، كيف يمكنكم تجنب هذه المشكلة؟
أنت فقط، الشخص، الذي لا يقضي أبدًا طلبات رفيقه في السكن.
الجمهور: يقول المغنطيس الذي وضعته على الثلاجة اشتري هذا.
ديفيد ج. مالان: مغنطيس-- نعم.
قائمة تسوق، صحيح-- ذهبتُ لشراء الحليب--
أوقفتوه عن الشراء.
دائمًا اتركوا ملاحظة، أليس كذلك؟
يمكنكم تبليغ تلك المعلومة.
يمكنكم وبشكل أكبر قفل الثلاجة، أليس كذلك؟
قفل الشيء، وإذن لا يمكن لرفيقكم في السكن
أن يفحص حالة الثلاجة في غيابكم، وبالتالي،
لا يجعلنا عُرضة لهذا.
وأستخدم كلمة قفل بشكل متعمد لأن،
في قواعد البيانات، ذلك هو كيف يتم حل هذا.
هناك ميزة في قواعد البيانات تُسمى أقفال.
أو تُسمى الإصدارات الأكثر روعة من هذا المُعاملات،
حيث يمكنكم ضمان شيء يُسمى آلية الرجوع،
حيث تعني آلية الرجوع أنه يمكنكم القيام بأشياء متعددة على التوالي
دون أن تتم مقاطعتكم.
إذن في حالة البنك، من الممكن، عبر SQL، باستخدام القليل من
الصيغ الأكثر روعة والتي لن نتعمق فيها اليوم لحل هذه المشكلة بقول،
أتعلمون ماذا؟
ابدأ في المعاملة التالية.
تحقق من حالة الحساب المصرفي، استقطع هذا المبلغ من المال،
والآن التزم بالنتائج.
وبينما أفعل ذلك، امنع أي شخص من الدخول.
لا تدع أي عميل آخر أو أي مستخدم آخر
أن يفعل بالضبط تلك المعلومات التي تمس البيانات نفسها حتى انتهي.
باختصار-- تدفعون ثمن، ربما.
حرفيًا تمنعون رفيقكم في السكن من الوصول إلى الثلاجة،
وهذا مزعج.
أو تمنعون العملاء الآخرين من القيام بمعاملات.
إذن آمل أن يكون الكمبيوتر سريعًا في هذا، وأنكم تقومون بالتسوق بسرعة.
ولكن قد ضمنتم على الأقل أن لديكم آلية الرجوع.
لا يمكن إدراج أي عملية في تسلسل العمليات الخاص بكم
عبر رفيقكم في السكن أو كمبيوتر آخر أو مؤشر ترابط.
إذن فهذه مشكلة مع قواعد البيانات سنقوم باختصارها فقط.
ويُمكن لـ GitHub أن يحل هذا، كيف؟
حسنًا، بعدم الاهتمام، من المحتمل.
لا أعرف ما الذي سيحدث إذا حاول العديد منّا.
أخمّن أنها ستعطي فقط n ناقص 1 منا رسالة خطأ تقول، معذرةً،
لم يعد اسم المستخدم هذا متوفرًا.
فكّروا في هذا.
إذا اشتريتم مُسبقًا تذاكر طيران، فهذه
مشكلة محلولة في تلك الصناعة.
سيكون هذا مزعج جدًا.
إذا فقط قضيتم ساعة من البحث المُرهِق عن سعر
جيد لتذكرة طائرة، تبدأون في البحث
بعد إضافتها إلى عربة التسوق الخاصة بكم.
وبعد خمس دقائق، بعد إدخال الاسم وعنوان البريد الإلكتروني ورقم بطاقة الائتمان
الخاصين بكم، لم تعد التذكرة موجودة.
إذن ما الذي تفعله الخطوط الجوية؟
في كثير من الأحيان يمنحونكم نافذة لمدة خمس دقائق.
وتعرض لكم بعض مواقع الويب الأروع الساعة قائلة،
نضمن هذا للخمس دقائق القادمة.
قد تفعل الفنادق هذا أيضًا حيث يقومون بقفل الثلاجة لكم
عبر تغيير قاعدة البيانات بطريقة ما ليقولوا، امم-امم.
لا يمكن لأي شخص آخر شراء هذه التذكرة أو هذه الحجرة للخمس دقائق القادمة،
وهذا ما يُشبه إلى حد كبير الملاحظة أو القفل.
إذن هذه النوع من الأشياء موجود في كل مكان حولنا.
لكن دعونا ننظر إلى مثال أخير الذي يُعد أسوأ تهديد على الإطلاق وهو هذا.
في السابق، سمحتُ لنفسي بالبحث بالاسم.
إذن q يساوي Brian أو q يساوي David أو Veronica أو ما شابه.
وماذا فعلتُ بتلك المعلومة؟
حسنًا، إذا عدنا إلى IDE ونظرنا في الواقع
إلى ذلك الملف في application.py، قمتُ بتنسيقه ببساطة باستخدام سلسلة F
داخل سلسلة SQL هذه.
ولكن ماذا إذا كان المستخدمين لديّ ضارّين قليلاً؟
ولنفترض أن شخصًا ما لا يريد فقط البحث عن Brian.
لكن أتعلمون ماذا؟
لنفترض أنه يفعل شيئًا على سبيل المثال، إن الاستعلام لديّ هو حذف من المُسجلين حيث--
عذرًا براين-- اسم يساوي Brian--
شيئًا من هذا القبيل.
الآن، هذا غير صالح في هذه اللحظة، لأن هذه السلسلة،
بينما يُسمَح لي بالتأكيد كتابتها،
سيتم إدخالها في التعليمة البرمجية لديّ، لكن منطقيًا في المكان الخطأ.
على سبيل المثال، سأبحث عن اسم شخص ما يُسمى "حذف من المُسجلين
حيث اسم يساوي Brian،" وهذا فقط سخيف.
سيقوم بإرجاع 0 من النتائج.
لكن ماذا إذا قمتُ بشيء من هذا القبيل حيث أقول
Brian أو حذف من المُسجلين عندما أُنهي
فكرة المبرمج ثم أبدأ بفكرة جديدة خاصة بي.
أو طريقة أخرى للقيام بهذا هي استخدام فاصلة منقوطة وهي صيغة خاصة، شيء من
هذا القبيل.
باختصار، يمكنني استنباط مدخل بشري ضار والذي
يُنهي فكرة المبرمج ويقوم بإرجاع صفر من الصفوف، لكن بالمناسبة،
أيضًا يقوم بتسلل استعلام مخادع إضافي في قاعدة البيانات.
هذا ما يُعرف بحقنة هجوم SQL.
وإذا كتبتم بشكل ساذج وسيئ جدًا، وغير صحيح تعليمة برمجية مثلما
فعلت-- لاتفعلوا ذلك أبدًا--
ستكونون مُعرضين لهذا الهجوم بالضبط
لأنكم تقوموا بإدخال مدخل المستخدم بشكل أعمى في سلسلة
ثم تقومون بتمريره إلى قاعدة بيانات.
هذا هو الخطأ الأساسي في الكثير من التطبيقات، واللغات
حين يجب عليكم عدم الثقة بالمستخدمين لديكم.
لا يهم إذا كان هذا فقط للطلاب في الحرم الجامعي
أو فقط لكم ولأصدقائكم.
لا تثقوا أبدًا، أبدًا في مدخل المستخدمين لأنه إما سيُخطئ
أحدهم في كتابة شيء ما ثم سينحرف شيئًا ما،
أو أن لديكم شخص سيء يحاول
اختراق موقع الويب أو التطبيق الخاص بكم
عبر تجربة هذه الأنواع من الأوامر.
وعليكم دائمًا كتابة تعليمة برمجية بشكل دفاعي.
إذن كيف يُمكنكم فعل هذا؟
يوجد بضعة طرق.
ولكن يتّضح أن، الأمر الخطير حول شيء
مثل الذي كتبته هي الفاصلة المنقوطة، على سبيل المثال،
وهي علامات الاقتباس فوق "elsewhere."
إذن الشيء الأكثر أمانًا لنفعله هو، بغض النظر عما يكتبه المستخدم، إلغاء الأشياء.
يمكنكم استخدام صيغة خاصة.
رأينا هذا في C-- بشكل عام، وضع خط مائل عكسي أمام شيء مما يعني،
لا تدعونه يحتفظ بسلوكه الافتراضي.
بدلاً من ذلك، عاملوه بشكل خاص.
إذن يمكنكم استخدام تعليمة برمجية خاصة في Python
التي تقول فقط قوموا بإزالة أي حروف غير صالحة، أو استبدال أشياء.
بصراحة، قد كنتم على الأرجح في موقع ويب حيث قد قيل لكم،
معذرةً، لا يمكنك استخدام هذا الحرف في كلمة المرور الخاصة بك.
أو معذرةً، لا يمكنك استخدام ذلك في اسم المستخدم الخاص بك.
هذا فقط غبي.
مثل، ذلك نهج كسول لهذا.
لا يوجد سبب لمنع المستخدمين من كتابة
أي حروف بلوحة المفاتيح لكلمة المرور الخاصة بهم وربما حتى
اسم المستخدم الخاص بهم.
هذه نوعًا ما طريقة كسولة للتصدي لهذا بقول،
امم-امم، لا أثق بأي علامة نسبة مئوية، أو أي فواصل منقوطة،
أو أي شرطات، أو أي فواصل عليا.
بدلاً من ذلك، فقط قوموا بإلغاء أشياء.
ولكن هذا سخيف لنا جميعًا في هذه الغرفة
كتابة التعليمة البرمجية الخاصة بنا من أجل إلغاء مدخل المستخدمين أو تنقيته، كما تُسمى،
أو تعقيمه، كما تُسمى-- الأشياء نفسها.
لمَ لا نستخدم فقط مكتبة؟
الآن، يوجد العديد من المكتبات هناك.
المكتبة التي نستخدمها في الوقت الحالي هي CS50.
وتقوم دالة EXECUTE بهذا لأجلنا.
بدلاً من استخدام سلاسل F، التي لا يجب استخدامها هكذا.
بدلاً من ذلك يجب عليكم القيام بهذا.
إذا أردتم إدخال قيمة عنصر نائب إلى استعلام SQL،
تستخدمون حرفياً تقليد قياسي، والذي تبنيناه أيضًا،
حيث يمكنكم فقط وضع اسم متغير، لكن مع وجود نقطتين أمامه.
ويمكن أن يكون أي شيء.
يمكن أن يكون q.
يمكن أن يكون x.
لا يهم.
لكنكم تريدون فقط إدخال قيمة ما هناك.
إذن سأُطلق عليها اسم، حسب التقليد.
ثم تقومون بإنهاء الاقتباس لديكم وإنهاء الفكرة.
ثم امضوا قدمًا وقوموا بتمرير القيمة الفعلية، اسم يساوي q.
والآن قمتم بإنشاء، بشكل ديناميكي،
سلسلة SQL عبر عنصر نائب وهو ليس
قوس متعرج عنصر نائب الخاص بـ Python.
هذا تقليد خاص في SQL حيث تقولون قم بإدخال قيمة هنا.
أي قيمة؟
سنقوم بإدخال قيمة الأسماء، q، أيًّا كان ما كتبه الإنسان.
وما ستفعله دالة execute لأجلكم
هو الخط المائل العكسي والإلغاء الرائعين
وستحميكم من بيانات المستخدم.
وهذه هي مدى بساطة الأمر حقًا.
لا يجب أن تكون مكتبة CS50.
هذا أمر شائع جدًا في جميع اللغات، ولكن عدد قليل جدًا من الأشخاص يعرفون ذلك
ويستخدمونه.
إذن معظم الوقت تقرأون عن اختراق بعض قواعد البيانات
أو عن سرقة بياناتكم، فذلك بسبب
سهو غبي من ذلك القبيل.
إذن، استخدموا فقط مكتبات وقوموا بإلغاء مدخل المستخدمين.
يمكننا أن نرى هذا الآن بشكل ملموس أكثر.
قد قام الطلاب الجامعيين جميعهم في الغرفة بالتأكيد
بتسجيل الدخول، إما على موقع الويب الخاص بييل أو بهارفارد،
الذي يبدو إلى حد ما شيئًا كهذا هنا.
تتم مطالبتكم باسم تسجيل الدخول وكلمة المرور الخاصة بكم،
أو Harvard key الخاص بكم أو ما شابه.
حسنًا، كيف يصبح هذا مؤثر بقيم فعلية؟
إذا كنت سأكتب عنوان البريد الإلكتروني لديّ--
ولكن صيغة غريبة مثل هذه-- دعونا ننظر إلى مثال.
علامة اقتباس Or علامة اقتباس 1 وعلامة إنهاء الاقتباس يساوي علامة اقتباس 1.
لاحظوا أنها ليست موزونة.
ينقصها علامة اقتباس هنا، وأخرى هنا.
لأن الافتراض هو أنه ربما تكون هارفارد مُعرضة لهذا.
لا أعتقد أنها كذلك.
لكن لنفترض أن التعليمة البرمجية التي تقوم بتشغيل Harvard key
وصفحة تسجيل الدخول إلى هارفارد تبدو نوعًا ما كهذه.
هذا سيء.
هذا أمر خطير لأنهم فقط يستخدمون سلاسل f أو سلاسل
تنسيق، والتي ستقوم فقط بإدخال أي شيء هناك بشكل أعمى.
إذن إذا سمحت للإنسان أن يكتب شيء مُشفر مثل ذلك،
لاحظوا ما حدث منطقيًا.
حيث اسم المستخدم يساوي me at example email provider.com وكلمة المرور
يساوي علامة اقتباس وعلامة إنهاء الاقتباس، إذن فارغة، أو 1 يساوي 1.
ولماذا 1 يساوي 1؟
إذا رجعتُ، لاحظوا أنه يوجد هنا علامة اقتباس وهنا.
والسبب في أنني لم أُنهي علامة الاقتباس الثانية هنا أو الأخرى
هنا هو لأنني أفترض، كشخص سيء،
أعتقد أن هارفارد ستقوم فقط بإدخال المدخل الخاص بي بشكل أعمى
في علامة اقتباس واحدة خاصة بها.
بالتالي، يمكنني إنهاء فكرتهم بشكل سخيف.
لكن لاحظوا، منطقيًا، ما الذي يحدث.
حدد المستخدمين جميعهم من قاعدة البيانات حيث اسم المستخدم هو me at example email
provider وكلمة المرور فارغة.
أو 1 يساوي 1.
حسنًا، متى 1 يساوي 1؟
دائمًا.
إذن فإن هذا سيقوم بإرجاع المستخدمين دائمًا من قاعدة البيانات،
ومن المفترض، بالتالي، يسمح لي بتسجيل الدخول كواحدًا من هؤلاء المستخدمين--
إذن الأمر بسيط بشكل لا يصدق للتصدي لهذا.
فقط استخدموا صيغة العنصر النائب ولا تثقوا بمدخل المستخدمين وقوموا بتعقيمه.
إن الصيغة في SQL ومكتبة CS50 بسيطة تمامًا مع تلك النقطتين.
ولكن في مكتبات أخرى، قد تكون نفسها تمامًا.
إذن أنتم الآن جميعًا، الحضور والطلاب على حدٍ سواء،
بدأتم في فئة صغيرة من الناس
في العالم الذي يفهم فكاهة العباقرة بشكل خاص.
قد تلاحظون هذا الميم الذي انتقل عبر الإنترنت منذ سنوات عديدة
وحتى الآن حيث قرر شخص ما إما بشكل ضار أو فكاهي
أن يرسم هذا على لوحة الرخصة الخاصة به.
دعونا نقوم بالتكبير.
لما قد يفعل شخص ما هذا؟
الجمهور: ماسحات ضوئية.
ديفيد ج. مالان: ماسحات ضوئية، نعم.
تتلاشي مقرّات محصلي الضرائب، على الأقل في الولايات المتحدة.
وبدلاً من ذلك لديهم كاميرات أو قارئات تقوم بمسح مقدمة سيارتكم
وتحاول إجراء OCR بشكل ضوئي، التعرف الضوئي على الحروف،
على لوحة الرخصة الخاصة بكم.
والافتراض هنا هو، ربما في بعض البلديات،
هناك بعض التعليمات البرمجية المكتوبة بشكل سيء حيث يتم بشكل أعمى إدخال
لوحة الرخصة الخاصة بكم في التعليمات البرمجية لديهم.
آملين أن تنهوا الفكرة حيث ZU 0666--
أيًّا كان ذلك، فإنه جزء من لوحة الرخصة--
لكن فاصلة منقوطة جدول إسقاط قاعدة البيانات نقطة نقطة نقطة.
ولم ننظر حتى إلى ذلك لأن كلمة إسقاط مبالغ فيها جدًا.
تقوم حرفيًا بحذف قاعدة البيانات نفسها.
ولكن هذه طريقة لطيفة للإعفاء من الضرائب.
وأكثر شيء متعارف عليه على الأرجح، XKCD وهو كارتون شائع جدًا يصدر بشكل متسلسل.
يستهدف العباقرة بشكل خاص.
وربما ستفهمون هذه الدعابة الآن كذلك بين دوائر CS.
[LAUGHING]
يمكنني سماع الضحك في كل مكان.
إذن من الآن فصاعدًا، إذا لم تأخذوا شيء آخر،
تذكروا جداول بوبي الصغيرة مع pset.
في النهاية، هل ستقومون في الواقع بتنفيذ CS50 Finance
وجمع هذه الأفكار جميعها.
شكرًا جزيلاً لانضمام الحضور جميعهم.
وسنراكم في المرة القادمة.
[APPLAUSE]