יצירה וניהול של אילוצי בדיקה

CHECK אילוץ מאפשר לציין שהערכים של עמודה אחת או יותר צריכים לעמוד בביטוי בוליאני. בדף הזה מוסבר איך להוסיף ולנהל את סוג האילוץ הזה במסדי נתונים של ניב GoogleSQL ובמסדי נתונים של ניב PostgreSQL.

הוספת אילוץ מסוג CHECK לטבלה חדשה

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

GoogleSQL

CREATE TABLE Concerts (
  ConcertId INT64,
  StartTime Timestamp,
  EndTime Timestamp,
  CONSTRAINT start_before_end CHECK(StartTime < EndTime),
) PRIMARY KEY (ConcertId);

PostgreSQL

CREATE TABLE Concerts (
  ConcertId BIGINT,
  StartTime TIMESTAMPTZ,
  EndTime TIMESTAMPTZ,
  CONSTRAINT start_before_end CHECK(StartTime < EndTime),
  PRIMARY KEY (ConcertId)
);

הגדרת האילוץ מתחילה במילת המפתח CONSTRAINT. בחרנו שם מפורש לאילוץ start_before_end בדוגמה הזו כדי שתוכלו למצוא אותו בהודעות שגיאה ובכל פעם שנצטרך להתייחס אליו. אם לא מציינים שם, Spanner מספק שם שמתחיל בקידומת CK_. השמות של האילוצים הם בתחום הסכימה, יחד עם השמות של הטבלאות והאינדקסים, והם חייבים להיות ייחודיים בתוך הסכימה. הגדרת אילוץ מסוג check מורכבת ממילת המפתח CHECK ואחריה ביטוי בסוגריים. הביטוי יכול להפנות רק לעמודות בטבלה הזו. בדוגמה הזו יש הפניה ל-StartTime ול-EndTime, והגבלת הבדיקה מוודאת ששעת ההתחלה של קונצרט תמיד קטנה משעת הסיום.

הערך של הביטוי של אילוץ הבדיקה מוערך כשמוסיפים שורה חדשה או כשמעדכנים את StartTime או EndTime של שורה קיימת. אם הביטוי מחזיר את הערך TRUE או NULL, השינוי בנתונים מותר על ידי אילוץ הבדיקה. אם הערך של הביטוי הוא FALSE, השינוי בנתונים לא מותר.

• ההגבלות הבאות חלות על תנאי של אילוץ מסוג check.expression

  • הביטוי יכול להתייחס רק לעמודות באותה טבלה.

  • הביטוי חייב להפנות לפחות לעמודה אחת שלא נוצרה, באופן ישיר או דרך עמודה שנוצרה שמפנה לעמודה שלא נוצרה.

  • הביטוי לא יכול להפנות לעמודות שהוגדרה בהן האפשרות allow_commit_timestamp.

  • הביטוי לא יכול להכיל שאילתות משנה.

  • הביטוי לא יכול להכיל פונקציות לא דטרמיניסטיות, כמו CURRENT_DATE() ו- CURRENT_TIMESTAMP().

הוספת אילוץ מסוג check לטבלה קיימת

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

ALTER TABLE Concerts
ADD CONSTRAINT concert_id_gt_0 CHECK (ConcertId > 0);

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

הסרת אילוץ בדיקה

הצהרת ה-DDL הבאה משמיטה אילוץ CHECK מהטבלה Concerts

ALTER TABLE Concerts
DROP CONSTRAINT concert_id_gt_0;

שינוי ביטוי של אילוץ בדיקה

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

הצגת המאפיינים של אילוץ מסוג check

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

אילו אילוצים של בדיקה מוגדרים במסד הנתונים שלי?

SELECT tc.CONSTRAINT_NAME, tc.TABLE_NAME, tc.CONSTRAINT_TYPE
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS as tc
WHERE tc.CONSTRAINT_TYPE = 'CHECK';

מה המצב הנוכחי של אילוצי הבדיקה במסד הנתונים שלי?

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

SELECT cc.CONSTRAINT_NAME, cc.SPANNER_STATE
FROM INFORMATION_SCHEMA.CHECK_CONSTRAINTS as cc;

המאמרים הבאים

• מידע נוסף על INFORMATION SCHEMA ב-Spanner