it-swarm.asia

هل العرض المتداخل تصميم جيد لقاعدة البيانات؟

لقد قرأت في مكان ما منذ زمن طويل. ينص الكتاب على أنه لا يجب السماح باستخدام طريقة عرض متداخلة في SQL Server. لست متأكدًا من سبب عدم قدرتنا على القيام بذلك أو ربما أتذكر بيانًا غير صحيح.

الطلاب

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

المعلمين

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

مدارس

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

في مكان عملي ، قمت بالتحقيق في أحد تطبيقات قواعد البيانات الداخلية لدينا. راجعت من خلال الكائنات وجدت أن هناك طبقتين أو ثلاث طبقات من كومة العرض بعضها البعض. لذلك كان ذلك يذكرني بما قرأته في الماضي. يمكن لأي شخص أن يساعد في شرح ذلك؟

إذا لم يكن الأمر كذلك ، فأنا أريد أن أعرف أنه يقتصر على SQL Server فقط أو هو مخصص لتصميم قاعدة البيانات بشكل عام.

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

43
Richard Sayakanit

بغض النظر عن المنصة ، تنطبق الملاحظات التالية.

(-) طرق عرض متداخلة:

  • يصعب فهمها وتصحيحها

    على سبيل المثال ما عمود الجدول الذي يشير إليه عمود العرض هذا؟ Lemme Dig through 4 مستويات لتعريفات العرض ...

  • تجعل من الصعب على مُحسِّن الاستعلام الخروج بخطة استعلام أكثر فعالية

    انظر هذا ، هذا ، هذا ، و هذا للحصول على أدلة قصصية. قارن مع this ، مما يدل على أن المُحسِّن غالبًا ما يكون ذكيًا بما يكفي لتفكيك طرق العرض المتداخلة بشكل صحيح وتحديد الخطة المثلى ، ولكن ليس بدون تكلفة تجميع.

    يمكنك قياس تكلفة الأداء من خلال مقارنة استعلام العرض باستعلام مكافئ مكتوب مقابل الجداول الأساسية.

(+) من ناحية أخرى ، تتيح لك المشاهدات المتداخلة:

  • مركزة وإعادة استخدام التجميعات أو قواعد العمل
  • تجريد الهيكل الأساسي الخاص بك (على سبيل المثال ، من مطوري قواعد البيانات الآخرين)

لقد وجدت أنها نادرا ما تكون ضرورية.


في مثالك ، تستخدم طرق عرض متداخلة لمركزية وإعادة استخدام تعريفات تجارية معينة (على سبيل المثال ، "ما هو الطالب المؤهل؟"). هذا استخدام صالح لطرق العرض المتداخلة. إذا كنت تقوم بصيانة قاعدة البيانات هذه أو ضبطها ، فقم بتحديد تكلفة الاحتفاظ بها مقابل تكلفة إزالتها.

  • Keep: من خلال الحفاظ على طرق العرض المتداخلة ، فإنك تتحمل المزايا والعيوب المذكورة أعلاه.

  • إزالة: لإزالة طرق العرض المتداخلة:

    1. تحتاج إلى استبدال كافة تكرارات طرق العرض بالاستعلامات الأساسية الخاصة بها.

    2. يجب أن تتذكر تحديث جميع الاستفسارات ذات الصلة إذا تغير تعريفك للطالب/المعلم/المدرسة المؤهلين ، بدلاً من تحديث تعريف العرض ذي الصلة فقط.

47
Nick Chammas

في بعض الأحيان يتم استخدام طرق العرض المتداخلة لمنع تكرار التجميعات. لنفترض أن لديك طريقة عرض تحسب الرسائل وتجميعها حسب معرف المستخدم ، قد يكون لديك طريقة عرض تحسب عدد المستخدمين الذين لديهم> 100 رسالة ، هذا النوع من الأشياء. يكون هذا أكثر فاعلية عندما تكون طريقة العرض الأساسية طريقة عرض مفهرسة - لا تحتاج بالضرورة إلى إنشاء طريقة عرض مفهرسة أخرى لتمثيل البيانات بمجموعة مختلفة قليلاً ، لأنك الآن تدفع مقابل صيانة الفهرس مرتين حيث من المحتمل أن يكون الأداء كافية ضد الرأي الأصلي.

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

26
Aaron Bertrand

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

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

أوافق على أن وجهات النظر يمكن أن تجعل الفوضى في تصحيح الأخطاء إذا كنت تقوم بإنشاء الاستعلامات وطرق العرض في نفس الوقت. ولكن ، إذا كنت تستخدم طريقة عرض موثوق بها ، فهذا يجعل التصحيح أسهل. أنت تعلم أن هذا العرض قد تم بالفعل من خلال الرنين ، لذلك أنت تعلم أنه على الأرجح لا يسبب المشكلة.

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

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

تعديل:

كمثال على كيف سيكون العرض أفضل من مجرد استعلام مسطح للجداول ... كان لدينا مقاول مؤقت يأتي لإجراء بعض التغييرات. أخبروه أن هناك وجهات نظر للأشياء ، لكنه قرر تسوية كل استفساراته. كانت الفوترة تنفد من بعض استفساراته. استمروا في الحصول على خطط رتب متعددة ومعدلات على الأشياء. تبين أن استفساراته كانت تفتقد المعايير للسماح فقط للأسعار بالفاتورة إذا كانت بين تاريخ البدء والنهاية كان من المفترض أن تستخدم خطة الأسعار ذلك/تلك الأسعار خلال. وجه الفتاة. إذا كان قد استخدم طريقة العرض ، لكان قد أخذ هذا المنطق في الاعتبار بالفعل.

في الأساس ، عليك أن تزن الأداء مقابل العقلانية. ربما يمكنك القيام بجميع أنواع الأشياء الفاخرة لزيادة أداء قاعدة البيانات. ولكن ، إذا كان هذا يعني أنه كابوس لشخص جديد أن يتولى/يحافظ ، فهل يستحق ذلك حقًا؟ هل حقا يستحق الرجل الجديد أن يلعب اضرب الخلد واضطر إلى العثور على جميع الاستفسارات التي تحتاج إلى تغيير منطقهم (ويخاطر به نسيانهم/بالإصبع) لهم ب/ج قرر شخص ما أن الآراء "سيئة" و لم تدمج بعض منطق الأعمال الأساسية في واحد يمكن استخدامه في مئات الاستفسارات الأخرى؟ الأمر متروك حقًا لعملك وفريق تكنولوجيا المعلومات/IS/DB الخاص بك. لكنني أفضل الوضوح والتوحيد الأحادي المصدر على الأداء.

7
blah blah

القضية الحقيقية ليست آراء متداخلة في حد ذاتها. المشكلة الحقيقية هي تكاثر المشاهدات المتداخلة حيث يضع المطورون تعديلات إضافية على طرق العرض الحالية. لقد وجدت استعلامات مع عرض متداخل 4 طبقات انضمت بالفعل إلى إحدى طرق العرض في تعريفها. إن نزعتنا إلى اتخاذ الطريق السهل بدلاً من تحليل المشكلة وحلها هي جذر المشكلة.

4
Ray

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

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

الأداء شيء آخر. طرق العرض التي تستند إلى طرق عرض أخرى ليست سوى استعلامات متعددة للتنفيذ. من الأسهل تجميع الاستعلام الأكبر معًا وإنشاء وظيفة وإنشاء جدول خارجها. أسهل ويحسن الأداء.

0
Narwhal