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

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

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

השאלות הבאות יישקלו:

1. באיזו צורה יש לאחסן dump מבנה של מסד נתונים במערכת בקרת גרסאות (להלן VCS)
2. כיצד לעקוב אחר שינויים במבנה מסד הנתונים לאחר שמירת dump
3. כיצד להעביר שינויים במבנה מסד הנתונים לסביבות אחרות ללא התנגשויות וקבצי הגירה ענקיים
4. כיצד לארגן תהליך של עבודה מקבילה על פרויקט על ידי מספר מפתחים
5. כיצד לפרוס בבטחה שינויים נוספים במבנה מסד הנתונים בסביבת ייצור
   

   SchemaKeeper מיועד לעבודה עם נהלים מאוחסנים שנכתבו בשפה PL/pgSQL. בדיקות עם שפות אחרות לא בוצעו, אז ייתכן שהשימוש לא יהיה יעיל או לא יהיה אפשרי.

כיצד לאחסן dump של מבנה מסד נתונים ב-VCS

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

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

סוג אובייקט
ערכתי
שם
נתיב יחסי לקובץ

שולחן
ציבורי
חשבונות
./public/tables/accounts.txt

הליך מאוחסן
ציבורי
aut (hash bigint)
./public/functions/auth(int8).sql

מבוא
הזמנה
תעריפי
./booking/views/tariffs.txt

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

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

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

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

על ידי שמירת dump של מבנה מסד הנתונים הנוכחי ב-VCS, אנו מקבלים את ההזדמנות לבדוק האם בוצעו שינויים במבנה מסד הנתונים לאחר יצירת ה-dump. בספרייה שומר סכמה כדי לזהות שינויים במבנה מסד הנתונים, מסופקת פונקציה verifyDump, המחזיר מידע על ההבדלים ללא תופעות לוואי.

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

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

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

לדוגמה, כדי ליצור פרוצדורה מאוחסנת חדשה בסכימה public פשוט צור קובץ חדש עם הסיומת .sql בספרייה public/functions, הצב בו את קוד המקור של הפרוצדורה המאוחסנת, כולל הבלוק CREATE OR REPLACE FUNCTION, ואז קרא לפונקציה deployDump. שינוי ומחיקה של הליך מאוחסן מתרחשים באותו אופן. לפיכך, הקוד נכנס גם ל-VCS וגם למסד הנתונים בו-זמנית.

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

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

deployDump מאפשר לך לשנות את הפרמטרים של פונקציה או סוג החזרה ללא פעולות נוספות, בעוד שבגישה הקלאסית תצטרך
לבצע תחילה DROP FUNCTION, ורק אז CREATE OR REPLACE FUNCTION.

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

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

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

העבודה עם העברות תתואר בפירוט רב יותר בסעיפים הבאים.

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

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

1. ייבא קובץ בעל מבנה בסיסי שייקרא למשל. base.sql
2. החלת הגירות
3. Вызов deployDump

base.sql היא נקודת ההתחלה שעליה מיושמות ומבוצעות העברות deployDumpכלומר, base.sql + миграции + deployDump = актуальная структура БД. אתה יכול ליצור קובץ כזה באמצעות כלי השירות pg_dump. בשימוש base.sql אך ורק בעת אתחול מסד הנתונים מאפס.

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

1. המפתח משיק בסביבתו refresh.sh ומקבל את מבנה מסד הנתונים הנוכחי
2. המפתח מתחיל לעבוד על המשימה שלפנינו, משנה את מסד הנתונים המקומי כדי לענות על הצרכים של הפונקציונליות החדשה (ALTER TABLE ... ADD COLUMN וכו)
3. לאחר השלמת המשימה, המפתח קורא לפונקציה saveDumpלבצע שינויים שבוצעו במסד הנתונים ב-VCS
4. הפעלה מחדש של מפתחים refresh.shאז verifyDumpאשר מציג כעת רשימה של שינויים שיש לכלול בהעברה
5. המפתח מעביר את כל שינויי המבנה לקובץ ההעברה, רץ שוב refresh.sh и verifyDump, וכן, אם ההעברה הידור כהלכה, verifyDump לא יציג הבדלים בין מסד הנתונים המקומי ל-dump שנשמר

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

בואו נבחן מצב קונפליקט באמצעות דוגמה: יש סניף לפתח, שממנו מסתעפים שני סניפים: תכונה 1 и תכונה 2, שאין להם סתירות איתם לפתח, אבל יש קונפליקטים אחד עם השני. המשימה היא למזג את שני הסניפים לתוך לפתח. במקרה זה, מומלץ קודם לאחד את אחד הסניפים לתוך לפתחולאחר מכן למזג לפתח לענף הנותר, פתרון קונפליקטים בענף הנותר, ואז מיזוג הענף האחרון לתוך לפתח. במהלך שלב פתרון הסכסוכים, ייתכן שיהיה עליך לתקן את קובץ ההעברה בסניף האחרון כך שיתאים ל-dump הסופי, הכולל את תוצאות המיזוגים.

כיצד לפרוס בבטחה שינויים נוספים במבנה מסד הנתונים בסביבת ייצור

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

כמו DDL ב-PostgreSQL הוא עסקה, מומלץ להקפיד על הוראת הפריסה הבאה, כך שבמקרה של שגיאה בלתי צפויה, תוכל לבצע "ללא כאב" ROLLBACK:

1. התחל עסקה
2. בצע את כל ההגירות בעסקה
3. באותה עסקה, בצע deployDump
4. מבלי להשלים את העסקה, בצע verifyDump. אם אין שגיאות, הפעל COMMIT. אם יש שגיאות, הפעל ROLLBACK

ניתן לשלב שלבים אלה בקלות בגישות קיימות לפריסת יישומים, כולל אפס זמן השבתה.

מסקנה

הודות לשיטות שתוארו לעיל, ניתן לסחוט ביצועים מקסימליים מפרויקטי "PHP + PostgreSQL", תוך ויתור על נוחות פיתוח מועטה יחסית להטמעת כל ההיגיון העסקי בקוד האפליקציה הראשי. יתר על כן, עיבוד נתונים ב PL/pgSQL לעתים קרובות נראה שקוף יותר ודורש פחות קוד מאשר אותה פונקציונליות שנכתבה ב-PHP.

מקור: www.habr.com