איזון כתיבה וקריאה במסד נתונים

בקודם статье תיארתי את הרעיון והיישום של מסד נתונים שנבנה על בסיס פונקציות, במקום טבלאות ושדות כמו במסדי נתונים יחסיים. הוא סיפק דוגמאות רבות המראות את היתרונות של גישה זו על פני הגישה הקלאסית. רבים מצאו אותם לא מספיק משכנעים.

במאמר זה אראה כיצד מושג זה מאפשר לאזן במהירות ובנוחות כתיבה וקריאה למסד הנתונים ללא כל שינוי בלוגיקת ההפעלה. פונקציונליות דומה נוסתה ליישום במערכות DBMS מסחריות מודרניות (בפרט, Oracle ו- Microsoft SQL Server). בסוף המאמר אראה שמה שהם עשו, בלשון המעטה, לא הצליח במיוחד.

תיאור

כמו קודם, להבנה טובה יותר אתחיל את התיאור בדוגמאות. נניח שצריך ליישם לוגיקה שתחזיר רשימה של מחלקות עם מספר העובדים בהן והשכר הכולל שלהן.

במסד נתונים פונקציונלי זה ייראה כך:

CLASS Department ‘Отдел’;
name ‘Наименование’ = DATA STRING[100] (Department);

CLASS Employee ‘Сотрудник’;
department ‘Отдел’ = DATA Department (Employee);
salary ‘Зарплата’ =  DATA NUMERIC[10,2] (Employee);

countEmployees ‘Кол-во сотрудников’ (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
salarySum ‘Суммарная зарплата’ (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);


המורכבות של ביצוע שאילתה זו בכל DBMS תהיה שווה ערך ל O(מספר עובדים)כי החישוב הזה מצריך סריקה של כל טבלת העובדים ולאחר מכן לקבץ אותם לפי מחלקות. תהיה גם תוספת קטנה (אנחנו מאמינים שיש הרבה יותר עובדים ממחלקות) בהתאם לתוכנית שנבחרה O(מספר יומן עובדים) או O(מספר מחלקות) לקיבוץ וכן הלאה.

ברור שתקורת הביצוע עשויה להיות שונה במערכות DBMS שונות, אך המורכבות לא תשתנה בשום צורה.

ביישום המוצע, ה-DBMS הפונקציונלי יפיק שאילתת משנה אחת שתחשב את הערכים הנדרשים עבור המחלקה, ולאחר מכן יבצע JOIN עם טבלת המחלקה כדי לקבל את השם. עם זאת, עבור כל פונקציה, בעת ההכרזה, ניתן להגדיר סמן MATERIALIZED מיוחד. המערכת תיצור אוטומטית שדה מתאים לכל פונקציה כזו. כאשר משנים את הערך של פונקציה, גם ערך השדה ישתנה באותה טרנזקציה. בעת גישה לפונקציה זו, תהיה גישה לשדה המחושב מראש.

בפרט, אם אתה מגדיר MATERIALIZED עבור פונקציות לספור עובדים и סכום משכורת, אז יתווספו לטבלה שני שדות עם רשימת המחלקות, אשר יאחסנו את מספר העובדים והשכר הכולל שלהם. בכל פעם שיש שינוי בעובדים, בשכרם או בשיוך המחלקה, המערכת תשנה אוטומטית את ערכי השדות הללו. השאילתה שלעיל תיגש ישירות לשדות הללו ותבוצע ב O(מספר מחלקות).

מהן ההגבלות? רק דבר אחד: לפונקציה כזו חייבת להיות מספר סופי של ערכי קלט שעבורם הערך שלה מוגדר. אחרת, אי אפשר יהיה לבנות טבלה שמאחסנת את כל הערכים שלה, שכן לא יכולה להיות טבלה עם מספר אינסופי של שורות.

לדוגמה:

employeesCount ‘Количество сотрудников с зарплатой > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;


פונקציה זו מוגדרת עבור מספר אינסופי של ערכים של N (לדוגמה, כל ערך שלילי מתאים). לכן, אינך יכול לשים עליו MATERIALIZED. אז זו מגבלה לוגית, לא טכנית (כלומר, לא בגלל שלא יכולנו ליישם אותה). אחרת, אין הגבלות. אתה יכול להשתמש בקבוצות, מיון, AND ו-OR, PARTITION, רקורסיה וכו'.

לדוגמה, בבעיה 2.2 של המאמר הקודם, אתה יכול לשים MATERIALIZED על שתי הפונקציות:

bought 'Купил' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y MATERIALIZED;
rating 'Рейтинг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y MATERIALIZED;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;


המערכת עצמה תיצור טבלה אחת עם מקשי סוג לקוח, המוצר и מספר שלם, יוסיף לו שני שדות ויעדכן את ערכי השדות שבהם בכל שינוי. כאשר מתבצעות קריאות נוספות לפונקציות הללו, הן לא יחושבו, אלא הערכים ייקראו מהשדות המתאימים.

באמצעות מנגנון זה, תוכל, למשל, להיפטר מרקורסיות (CTE) בשאילתות. בפרט, שקול קבוצות היוצרות עץ תוך שימוש ביחסי ילד/הורה (לכל קבוצה יש קישור להורה שלה):

parent = DATA Group (Group);


במסד נתונים פונקציונלי, ניתן לציין לוגיקה של רקורסיה באופן הבא:

level (Group child, Group parent) = RECURSION 1l IF child IS Group AND parent == child
                                                             STEP 2l IF parent == parent($parent);
isParent (Group child, Group parent) = TRUE IF level(child, parent) MATERIALIZED;


מאז בשביל הפונקציה הוא הורה מסומן MATERIALIZED, אז תיווצר עבורו טבלה עם שני מפתחות (קבוצות), שבה השדה הוא הורה יהיה נכון רק אם המפתח הראשון הוא בן של השני. מספר הערכים בטבלה זו יהיה שווה למספר הקבוצות כפול העומק הממוצע של העץ. אם אתה צריך, למשל, לספור את מספר הצאצאים של קבוצה מסוימת, אתה יכול להשתמש בפונקציה הזו:

childrenCount (Group g) = GROUP SUM 1 IF isParent(Group child, g);


לא יהיה CTE בשאילתת SQL. במקום זאת יהיה GROUP BY פשוט.

באמצעות מנגנון זה, תוכל גם לבטל בקלות את מסד הנתונים במידת הצורך:

CLASS Order 'Заказ';
date 'Дата' = DATA DATE (Order);

CLASS OrderDetail 'Строка заказа';
order 'Заказ' = DATA Order (OrderDetail);
date 'Дата' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;


בעת קריאה לפונקציה נתונים עבור שורת ההזמנה, השדה שעבורו קיים אינדקס ייקרא מהטבלה עם שורות ההזמנה. כאשר תאריך ההזמנה משתנה, המערכת עצמה תחשב מחדש אוטומטית את התאריך המפורק בשורה.

יתרונות

בשביל מה כל המנגנון הזה? ב-DBMSs קלאסי, ללא שכתוב שאילתות, מפתח או DBA יכולים רק לשנות אינדקסים, לקבוע סטטיסטיקות ולהגיד למתכנן השאילתות כיצד לבצע אותם (והטיפים זמינים רק ב-DBMS מסחריים). לא משנה כמה הם ינסו, הם לא יוכלו להשלים את השאילתה הראשונה במאמר ב O (מספר מחלקות) מבלי לשנות שאילתות או להוסיף טריגרים. בסכימה המוצעת, בשלב הפיתוח אינך צריך לחשוב על מבנה אחסון הנתונים ובאילו צבירות להשתמש. כל זה ניתן לשינוי בקלות תוך כדי תנועה, ישירות בפעולה.

בפועל זה נראה כך. יש אנשים שמפתחים היגיון ישירות על סמך המשימה שעל הפרק. הם לא מבינים אלגוריתמים ומורכבותם, לא תוכניות ביצוע, לא סוגי הצטרפות, ולא כל רכיב טכני אחר. האנשים האלה הם יותר אנליסטים עסקיים מאשר מפתחים. לאחר מכן, כל זה נכנס לבדיקה או הפעלה. מאפשר רישום של שאילתות ארוכות טווח. כאשר מזוהה שאילתה ארוכה, אז אנשים אחרים (טכניים יותר - בעצם DBA) מחליטים להפעיל MATERIALIZED בפונקציית ביניים כלשהי. זה מאט מעט את ההקלטה (שכן זה מצריך עדכון שדה נוסף בעסקה). עם זאת, לא רק שאילתה זו מואצת משמעותית, אלא גם כל השאר שמשתמשים בפונקציה זו. יחד עם זאת, ההחלטה איזו פונקציה לממש היא קלה יחסית. שני פרמטרים עיקריים: מספר ערכי הקלט האפשריים (זה כמה רשומות יהיו בטבלה המתאימה), ובאיזו תדירות הוא משמש בפונקציות אחרות.

אנלוגים

למערכות DBMS מסחריות מודרניות יש מנגנונים דומים: MATERIALIZED VIEW עם FAST REFRESH (Oracle) ו- INDEXED VIEW (Microsoft SQL Server). ב-PostgreSQL לא ניתן לעדכן MATERIALIZED VIEW בעסקה, אלא רק על פי בקשה (ואפילו בהגבלות מאוד מחמירות), אז אנחנו לא מתחשבים בזה. אבל יש להם כמה בעיות שמגבילות באופן משמעותי את השימוש בהם.

ראשית, אתה יכול לאפשר התממשות רק אם כבר יצרת VIEW רגיל. אחרת, תצטרך לכתוב מחדש את הבקשות הנותרות כדי לגשת לתצוגה החדשה שנוצרה כדי להשתמש בהתממשות זו. או להשאיר הכל כמו שהוא, אבל זה יהיה לפחות לא יעיל אם יש נתונים מסוימים שכבר מחושבים מראש, אבל שאילתות רבות לא תמיד משתמשות בהם, אלא מחשבות אותם מחדש.

שנית, יש להם מספר עצום של הגבלות:

אורקל

5.3.8.4 הגבלות כלליות על רענון מהיר

השאילתה המגדירה של התצוגה הממשית מוגבלת באופן הבא:

• התצוגה המתממשת אינה יכולה להכיל הפניות לביטויים שאינם חוזרים על עצמם כמו SYSDATE ו ROWNUM.
• אסור שהתצוגה הממומשת תכיל הפניות ל RAW or LONG RAW סוגי מידע.
• זה לא יכול להכיל א SELECT שאילתת משנה ברשימה.
• הוא אינו יכול להכיל פונקציות אנליטיות (לדוגמה, RANK) בתוך ה SELECT סעיף.
• זה לא יכול להתייחס לטבלה שבה א XMLIndex מדד מוגדר.
• זה לא יכול להכיל א MODEL סעיף.
• זה לא יכול להכיל א HAVING סעיף עם שאילתת משנה.
• הוא לא יכול להכיל שאילתות מקוננות שיש להן ANY, ALL, או NOT EXISTS.
• זה לא יכול להכיל א [START WITH …] CONNECT BY סעיף.
• זה לא יכול להכיל טבלאות פירוט מרובות באתרים שונים.
• ON COMMIT לתצוגות שהתממשו לא יהיו טבלאות פרטים מרוחקים.
• תצוגות משובצות חייבות להיות צירוף או מצטבר.
• תצוגות הצטרפות ממומשות וצפיות מצטברות שהתממשו עם א GROUP BY לא ניתן לבחור בסעיף מתוך טבלה מאורגנת באינדקס.

5.3.8.5 הגבלות על רענון מהיר בצפיות שהתממשו עם הצטרפות בלבד

להגדרת שאילתות עבור תצוגות מימושות עם צירוף בלבד וללא אגרגטים יש את ההגבלות הבאות על רענון מהיר:

• כל ההגבלות מ- «הגבלות כלליות על רענון מהיר".
• הם לא יכולים לקבל GROUP BY סעיפים או אגרגטים.
• Rowids של כל השולחנות ב- FROM הרשימה חייבת להופיע ב- SELECT רשימה של השאילתה.
• יומני תצוגה ממומשים חייבים להתקיים עם שורות עבור כל טבלאות הבסיס ב- FROM רשימה של השאילתה.
• אינך יכול ליצור תצוגה ממומשת ניתנת לרענון מהיר ממספר טבלאות עם חיבורים פשוטים הכוללים עמודת סוג אובייקט ב- SELECT הצהרה.

כמו כן, שיטת הרענון שתבחר לא תהיה יעילה בצורה מיטבית אם:

• השאילתה המגדירה משתמשת בצירוף חיצוני שמתנהג כמו צירוף פנימי. אם השאילתה המגדירה מכילה צירוף כזה, שקול לשכתב את השאילתה המגדירה כך שתכיל צירוף פנימי.
• אל האני SELECT רשימה של התצוגה הממומשת מכילה ביטויים על עמודות ממספר טבלאות.

5.3.8.6 הגבלות על רענון מהיר של צפיות ממומשות עם אגרגטים

להגדרת שאילתות עבור תצוגות מתממשות עם צבירות או צירוף יש את ההגבלות הבאות על רענון מהיר:

• כל ההגבלות מ- «הגבלות כלליות על רענון מהיר".

רענון מהיר נתמך בשניהם ON COMMIT ו ON DEMAND צפיות שהתממשו, אולם חלות ההגבלות הבאות:

• כל הטבלאות בתצוגת התממשות חייבות לכלול יומני תצוגות שהתממשו, ויומני התצוגות שהתממשו חייבים:
  • הכיל את כל העמודות מהטבלה שאליהם מתייחסים בתצוגה המיושמת.
  • ציין עם ROWID ו INCLUDING NEW VALUES.
  • ציין את SEQUENCE סעיף אם הטבלה צפויה לכלול שילוב של הוספות/טעינות ישירה, מחיקות ועדכונים.

• רק SUM, COUNT, AVG, STDDEV, VARIANCE, MIN ו MAX נתמכים לרענון מהיר.
• COUNT(*) יש לציין.
• פונקציות מצטברות חייבות להתרחש רק כחלק החיצוני ביותר של הביטוי. כלומר, אגרגטים כגון AVG(AVG(x)) or AVG(x)+ AVG(x) לא מורשים.
• עבור כל מצרף כגון AVG(expr), המקביל COUNT(expr) חייב להיות נוכח. אורקל ממליצה על כך SUM(expr) להיות מוגדר.
• If VARIANCE(expr) or STDDEV(expr) מצוין, COUNT(expr) ו SUM(expr) יש לציין. אורקל ממליצה על כך SUM(expr *expr) להיות מוגדר.
• אל האני SELECT העמודה בשאילתה המגדירה אינה יכולה להיות ביטוי מורכב עם עמודות מטבלאות בסיס מרובות. דרך אפשרית לעקיפת הבעיה היא להשתמש בתצוגה ממומשת מקוננת.
• אל האני SELECT הרשימה חייבת להכיל הכל GROUP BY עמודות.
• התצוגה המתממשת אינה מבוססת על טבלה מרוחקת אחת או יותר.
• אם אתה משתמש ב- CHAR סוג הנתונים בעמודות הסינון של יומן תצוגה ממומשת, ערכות התווים של האתר הראשי והתצוגה המממשת חייבות להיות זהות.
• אם התצוגה שהתממשה כוללת אחת מהאפשרויות הבאות, רענון מהיר נתמך רק בתוספות DML קונבנציונליות ובטעינות ישירה.
  • צפיות ממומשות עם MIN or MAX אגרגטים
  • השקפות ממומשות אשר יש SUM(expr) אבל לא COUNT(expr)
  • השקפות ממומשות בלי COUNT(*)

  השקפה מתממשת כזו נקראת ראייה מתממשת בלבד.

• נוף התממש עם MAX or MIN ניתן לרענן במהירות לאחר מחיקה או הצהרות DML מעורבות אם אין לו א WHERE סעיף.
  לרענון המהיר המקסימלי/דקה לאחר מחיקה או DML מעורב אין אותה התנהגות כמו במקרה של הוספה בלבד. זה מוחק ומחשב מחדש את ערכי המקסימום/דקה עבור הקבוצות המושפעות. אתה צריך להיות מודע להשפעת הביצועים שלו.
• תצוגות ממומשות עם תצוגות או שאילתות משנה ב- FROM ניתן לרענן במהירות את הסעיף בתנאי שניתן למזג לחלוטין את התצוגות. למידע על אילו תצוגות יתמזגו, ראה Oracle Database SQL Reference Language.
• אם אין צירוף חיצוני, ייתכן שיש לך בחירות שרירותיות והצטרפות ב- WHERE סעיף.
• תצוגות מצטברות מתממשות עם חיבורים חיצוניים ניתנות לרענון מהיר לאחר DML קונבנציונלי ועומסים ישירים, בתנאי שרק הטבלה החיצונית שונתה. כמו כן, אילוצים ייחודיים חייבים להתקיים בעמודות החיבור של טבלת החיבור הפנימית. אם יש חיבורים חיצוניים, כל החיבורים חייבים להיות מחוברים על ידי ANDוחייבים להשתמש בשוויון (=) מפעיל.
• לצפיות שהתממשו עם CUBE, ROLLUP, קבוצות קיבוץ או שרשור שלהן, חלות ההגבלות הבאות:
  • אל האני SELECT רשימה צריכה להכיל מבחין קיבוץ שיכול להיות א GROUPING_ID לתפקד על כולם GROUP BY ביטויים או GROUPING מתפקד אחד לכל אחד GROUP BY ביטוי. לדוגמה, אם ה GROUP BY סעיף ההשקפה המתממשת הוא "GROUP BY CUBE(a, b)", אז ה SELECT רשימה צריכה להכיל או "GROUPING_ID(a, b)» או «GROUPING(a) AND GROUPING(b)» כדי שהתצוגה המתממשת תהיה ניתנת לרענון מהיר.
  • GROUP BY לא אמור לגרום לקיבוץ כפול. לדוגמה, "GROUP BY a, ROLLUP(a, b)"אינו ניתן לרענון מהיר מכיוון שהוא גורם לקבוצות כפולות"(a), (a, b), AND (a)".

5.3.8.7 הגבלות על רענון מהיר של צפיות שהתממשו עם UNION ALL

השקפות ממומשות עם ה UNION ALL סט מפעיל לתמוך את REFRESH FAST אפשרות אם מתקיימים התנאים הבאים:

• השאילתה המגדירה חייבת לכלול את UNION ALL מפעיל ברמה העליונה.

  אל האני UNION ALL לא ניתן להטמיע אופרטור בתוך שאילתת משנה, למעט חריג אחד: ה UNION ALL יכול להיות בשאילתת משנה ב- FROM סעיף בתנאי שהשאילתה המגדירה היא בצורה SELECT * FROM (הצג או שאילתת משנה עם UNION ALL) כמו בדוגמה הבאה:

  CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM customers c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker FROM customers c WHERE c.cust_last_name = 'ג'ונס'); צור תצוגה חומרית unionall_inside_view_mv רענון מהיר לפי דרישה לפי בחירה * FROM view_with_unionall;
  

  שימו לב שהנוף view_with_unionall עונה על הדרישות לרענון מהיר.

• כל בלוק שאילתה ב- UNION ALL השאילתה חייבת לעמוד בדרישות של תצוגה מתממשת ניתנת לרענון מהירה עם אגרגטים או תצוגה ממומשת ניתנת לרענון מהירה עם חיבורים.

  יש ליצור על הטבלאות את יומני התצוגה הממומשים המתאימים כנדרש עבור הסוג המתאים של תצוגה מתממשת ניתנת לרענון מהיר.
  שים לב שמסד הנתונים של Oracle מאפשר גם את המקרה המיוחד של תצוגת טבלה אחת שהתממשה עם חיבורים רק בתנאי ROWID העמודה נכללה ב- SELECT רשימה וביומן התצוגה הממומש. זה מוצג בשאילתה המגדירה של התצוגה view_with_unionall.

• אל האני SELECT רשימה של כל שאילתה חייבת לכלול א UNION ALL סמן, ואת UNION ALL עמודה חייבת להיות בעלת ערך מספרי קבוע או מחרוזת קבועה בכל אחת מהן UNION ALL ענף. יתרה מכך, עמודת הסמן חייבת להופיע באותו מיקום סידורי ב- SELECT רשימה של כל בלוק שאילתה. ראה"UNION ALL מרקר ושכתוב שאילתה» למידע נוסף בנושא UNION ALL סמנים.
• תכונות מסוימות, כגון חיבורים חיצוניים, שאילתות תצוגה מצטברת מצטברת להוספה בלבד וטבלאות מרוחקות אינן נתמכות עבור תצוגות שהתממשו עם UNION ALL. עם זאת, שימו לב שניתן לרענן במהירות תצוגות שהתממשו בשימוש בשכפול, שאינן מכילות צירוף או אגרגטים, כאשר UNION ALL או משתמשים בטבלאות מרוחקות.
• יש להגדיר את פרמטר אתחול התאימות ל-9.2.0 או גבוה יותר כדי ליצור תצוגה מתממשת הניתנת לרענון מהיר עם UNION ALL.

אני לא רוצה להעליב את מעריצי אורקל, אבל אם לשפוט לפי רשימת ההגבלות שלהם, נראה שהמנגנון הזה נכתב לא במקרה הכללי, תוך שימוש במודל כלשהו, ​​אלא על ידי אלפי הודים, שבו ניתנה לכולם ההזדמנות כתבו את הסניף שלו, וכל אחד מהם עשה מה שהוא יכול ועשה. שימוש במנגנון זה להיגיון אמיתי הוא כמו הליכה בשדה מוקשים. אתה יכול להשיג מוקש בכל עת על ידי פגיעה באחת ההגבלות הלא ברורות. איך זה עובד זו גם שאלה נפרדת, אבל זה מעבר לתחום המאמר הזה.

Microsoft SQL Server

דרישות נוספות

בנוסף לאפשרויות ה-SET ודרישות הפונקציה הדטרמיניסטית, יש לעמוד בדרישות הבאות:

• המשתמש שמבצע CREATE INDEX חייב להיות הבעלים של התצוגה.
• כאשר אתה יוצר את האינדקס, ה IGNORE_DUP_KEY יש להגדיר את האפשרות ל-OFF (הגדרת ברירת המחדל).
• יש להתייחס לטבלאות בשמות של שני חלקים, סכימה.שם לוח בהגדרת התצוגה.
• יש ליצור פונקציות המוגדרות על ידי המשתמש שהפנותם אליהם בתצוגה באמצעות ה- WITH SCHEMABINDING אוֹפְּצִיָה.
• יש להפנות לכל פונקציה המוגדרת על ידי משתמש בתצוגה באמצעות שמות שני חלקים, ..
• מאפיין הגישה לנתונים של פונקציה מוגדרת על ידי משתמש חייב להיות NO SQL, ומאפיין גישה חיצוני חייב להיות NO.
• פונקציות זמן ריצה משותפות (CLR) יכולות להופיע ברשימת הבחירה של התצוגה, אך אינן יכולות להיות חלק מההגדרה של מפתח האינדקס המקובץ. פונקציות CLR אינן יכולות להופיע בסעיף WHERE של התצוגה או בסעיף ON של פעולת JOIN בתצוגה.
• פונקציות ושיטות CLR של סוגים מוגדרים על ידי CLR המשמשים בהגדרת התצוגה חייבים להיות בעלי המאפיינים מוגדרים כפי שמוצג בטבלה הבאה.

  נכס
  הערות

  דטרמיניסטית = אמת
  יש להצהיר במפורש כתכונה של שיטת Microsoft .NET Framework.

  מדויק = נכון
  יש להצהיר במפורש כתכונה של שיטת .NET Framework.

  גישה לנתונים = ללא SQL
  נקבע על ידי הגדרת תכונת DataAccess ל-DataAccessKind.None ותכונת SystemDataAccess ל-SystemDataAccessKind.None.

  גישה חיצונית = לא
  ברירת המחדל של מאפיין זה הוא NO עבור שגרות CLR.

• יש ליצור את התצוגה באמצעות ה- WITH SCHEMABINDING אוֹפְּצִיָה.
• התצוגה חייבת להתייחס רק לטבלאות בסיס שנמצאות באותו מסד נתונים כמו התצוגה. התצוגה אינה יכולה להתייחס לתצוגות אחרות.
• הצהרת SELECT בהגדרת התצוגה אינה יכולה להכיל את רכיבי Transact-SQL הבאים:

  COUNT
  פונקציות ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, ו- OPENXML)
  OUTER מצטרף (LEFT, RIGHT, או FULL)

  טבלה נגזרת (מוגדרת על ידי ציון א SELECT הצהרה ב FROM סָעִיף)
  מצטרפת עצמית
  ציון עמודות באמצעות SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP, או AVG
  ביטוי טבלה נפוץ (CTE)

  לצוף1, טֶקסט, ntext, תמונה, XML, או פילם סטרים עמודות
  שאילתא משנה
  OVER סעיף, הכולל דירוג או פונקציות חלון מצטבר

  פרדיקטים של טקסט מלא (CONTAINS, FREETEXT)
  SUM פונקציה המתייחסת לביטוי nullable
  ORDER BY

  פונקציית צבירה מוגדרת על ידי CLR
  TOP
CUBE, ROLLUP, או GROUPING SETS מפעילי

  MIN, MAX
UNION, EXCEPT, או INTERSECT מפעילי
  TABLESAMPLE

  משתני טבלה
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  קבוצות עמודות דלילות
  פונקציות מוטבעות (TVF) או רב-הצהרות בעלות ערכי טבלה (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 התצוגה האינדקסית יכולה להכיל לצוף עמודים; עם זאת, לא ניתן לכלול עמודות כאלה במפתח האינדקס המקובץ.

• If GROUP BY קיים, ההגדרה VIEW חייבת להכיל COUNT_BIG(*) ואסור להכיל HAVING. אלה GROUP BY ההגבלות חלות רק על הגדרת התצוגה האינדקסית. שאילתה יכולה להשתמש בתצוגת אינדקס בתוכנית הביצוע שלה גם אם היא לא עומדת באלה GROUP BY הגבלות.
• אם הגדרת התצוגה מכילה א GROUP BY סעיף, המפתח של האינדקס המקובץ הייחודי יכול להתייחס רק לעמודות המצוינות ב- GROUP BY סעיף.

ברור כאן שהאינדיאנים לא היו מעורבים, מכיוון שהם החליטו לעשות זאת על פי התוכנית "אנחנו נעשה מעט, אבל טוב". כלומר, יש להם יותר מוקשים בשטח, אבל המיקום שלהם שקוף יותר. הדבר המאכזב ביותר הוא המגבלה הזו:

התצוגה חייבת להתייחס רק לטבלאות בסיס שנמצאות באותו מסד נתונים כמו התצוגה. התצוגה אינה יכולה להתייחס לתצוגות אחרות.

בטרמינולוגיה שלנו, זה אומר שפונקציה לא יכולה לגשת לפונקציה שהתממשה אחרת. זה מקצץ את כל האידיאולוגיה שבניצן.
כמו כן, מגבלה זו (ועוד בטקסט) מפחיתה מאוד את מקרי השימוש:

הצהרת SELECT בהגדרת התצוגה אינה יכולה להכיל את רכיבי Transact-SQL הבאים:

COUNT
פונקציות ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, ו- OPENXML)
OUTER מצטרף (LEFT, RIGHT, או FULL)

טבלה נגזרת (מוגדרת על ידי ציון א SELECT הצהרה ב FROM סָעִיף)
מצטרפת עצמית
ציון עמודות באמצעות SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, או AVG
ביטוי טבלה נפוץ (CTE)

לצוף1, טֶקסט, ntext, תמונה, XML, או פילם סטרים עמודות
שאילתא משנה
OVER סעיף, הכולל דירוג או פונקציות חלון מצטבר

פרדיקטים של טקסט מלא (CONTAINS, FREETEXT)
SUM פונקציה המתייחסת לביטוי nullable
ORDER BY

פונקציית צבירה מוגדרת על ידי CLR
TOP
CUBE, ROLLUP, או GROUPING SETS מפעילי

MIN, MAX
UNION, EXCEPT, או INTERSECT מפעילי
TABLESAMPLE

משתני טבלה
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

קבוצות עמודות דלילות
פונקציות מוטבעות (TVF) או רב-הצהרות בעלות ערכי טבלה (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOINS, UNION, ORDER BY ואחרים אסורים. אולי היה קל יותר לציין במה אפשר להשתמש ולא במה אי אפשר להשתמש. הרשימה כנראה תהיה הרבה יותר קצרה.

לסיכום: סט עצום של הגבלות בכל (בואו נציין מסחרי) DBMS לעומת אף אחד (למעט אחד הגיוני, לא טכני) בטכנולוגיית LGPL. עם זאת, יש לציין שהטמעת מנגנון זה בלוגיקה רלציונית היא קצת יותר קשה מאשר בלוגיקה הפונקציונלית המתוארת.

Реализация

איך זה עובד? PostgreSQL משמש כ"מכונה וירטואלית". יש בפנים אלגוריתם מורכב שבונה שאילתות. כאן קוד המקור. ואין רק קבוצה גדולה של היוריסטיות עם חבורה של אם. אז אם יש לך כמה חודשים ללמוד, אתה יכול לנסות להבין אדריכלות.

האם זה עובד ביעילות? די יעיל. למרבה הצער, קשה להוכיח זאת. אני יכול רק לומר שאם לוקחים בחשבון את אלפי השאילתות שקיימות באפליקציות גדולות, אז בממוצע הן יעילות יותר מאלה של מפתח טוב. מתכנת SQL מעולה יכול לכתוב כל שאילתה בצורה יעילה יותר, אבל עם אלף שאילתות פשוט לא תהיה לו המוטיבציה או הזמן לעשות את זה. הדבר היחיד שאני יכול לצטט כעת כהוכחה לאפקטיביות הוא שכמה פרויקטים עובדים על הפלטפורמה הבנויה על DBMS זה מערכות ERP, שיש להם אלפי פונקציות MATERIALIZED שונות, עם אלפי משתמשים ומסדי נתונים של טרה-בייט עם מאות מיליוני רשומות הפועלות על שרת רגיל של שני מעבדים. עם זאת, כל אחד יכול לבדוק/להפריך את האפקטיביות על ידי הורדה פלטפורמה ו-PostgreSQL, נדלק רישום שאילתות SQL ומנסה לשנות את ההיגיון והנתונים שם.

במאמרים הבאים אדבר גם על איך אפשר להגדיר הגבלות על פונקציות, עבודה עם הפעלות שינוי ועוד ועוד.

מקור: www.habr.com