وجهات النظر وتجريد البيانات

ستلاحظ خلال دروسنا أن الاستعلامات (خصوصًا الاستعلامات المعقدة JOIN أو التجميعات مثل GROUP BY) تبدأ في أن تصبح طويلة ومليئة بالقواعد والحسابات.

ماذا لو كانت هناك طريقة ** لحفظ الاستعلام المكتمل عقليًا وإخفائه عن العرض، والتظاهر منذ ذلك الحين بأنه، لجميع المقاصد والأغراض، "جدول" عادي لقاعدة البيانات **؟

مرحبا بكم في عالم المشاهدات.

إنشاء عرض

العرض هو في الأساس استعلام SQL مسمى ومستمر، ولكنه يتصرف تمامًا مثل الجدول "الافتراضي"!

CREATE VIEW user_spending AS
SELECT
  c.id,
  c.first_name,
  SUM(o.amount) as total_spent
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;

منتهي! الآن، بدلًا من الاضطرار دائمًا إلى إعادة JOIN وGROUP BY، عليك فقط كتابة استعلامات عادية تمامًا:

SELECT * FROM user_spending WHERE total_spent > 100;
-- Postgres dietro le quinte richiamerà automaticamente la grande formula.

المشاهدات و"البيانات في الوقت الحقيقي"

من الأساطير الشائعة جدًا الاعتقاد بأن المشاهدات تأخذ البيانات، وتحسب المبالغ مثل الأسعار أو التصنيفات وتنتج بعض اللقطات الحزينة المستمرة، مثل الصورة الفوتوغرافية. خطأ (دائما تقريبا)! افتراضيًا، تكون طرق العرض افتراضية: في كل مرة تضع فيها اسم طريقة عرض في التحديد الخاص بك، يقوم Postgres خلف الكواليس بدمج طلبك عن طريق تشغيل حساب في الوقت الفعلي بناءً على حالة قاعدة البيانات في تلك المللي ثانية بالضبط. لذلك لن تقرأ أبدًا البيانات القديمة.

لماذا هم؟

• البساطة: طرق العرض تحمي التطبيقات الخارجية من التغييرات. إذا علم فريق الواجهة الأمامية أن عليه قراءة البيانات من طريقة العرض top_selling، فلا داعي للقلق إذا قمنا غدًا بتعديل قاعدة البيانات عن طريق إضافة ثلاث علاقات وسيطة لسحب أفضل البائعين!
• الأمان والفصل: في قواعد البيانات الضخمة، يمكن للعرض أن يحدد مسبقًا جزءًا من بيانات المستخدم ويخفيها عن المطورين الخارجيين، مما يمنحهم الوصول (على سبيل المثال) فقط إلى عرض فرعي للتحليلات التي تم مسحها من الأسماء الحقيقية.

إسقاط طريقة العرض

تمامًا مثل الجداول، عندما لا تكون هناك حاجة إليها، يمكنك المتابعة باستخدام الأمر DROP:

DROP VIEW user_spending;

جربه

استدعاء طريقة عرض