MySQL ו-PostgreSQL כאפשרויות backend מובנות

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

במערכת ארגונית מסד הנתונים אינו נקבע רק לפי העדפת המפתח. לארגון עשויים להיות תקני תפעול, צוות מסדי נתונים, נהלי גיבוי קיימים, דרישות ספק ענן או מגבלות אירוח מנוהל. לכן Sapphire I.C.D.S. תומכת בשתי אפשרויות backend מובנות, MySQL ו-PostgreSQL, ואינה כופה על כל התקנה מסד נתונים יחיד שנבחר מראש.

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

חוזה אחד מעל שני דרייברים

השכבות הגבוהות של Sapphire I.C.D.S. אינן אמורות להיות תלויות ישירות בספריית הלקוח של מסד מסוים. בקר הנתונים קורא את סוג ה-backend מן התצורה ומקבל את הדרייבר המובנה המתאים. המודול הקורא ממשיך להשתמש במערך משותף של פעולות: אחזור שורות, שינוי נתונים, ערכים יחידים, הוספה באצווה, עסקאות ופעולות סכמה.

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

תבניות SQL נפרדות במקום מחרוזות מותנות

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

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

מה נשאר משותף למודולים

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

מה הבחירה אינה עושה אוטומטית

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

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

כיצד לבחור בין MySQL ל-PostgreSQL

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

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

שוויון התנהגות דורש משמעת פיתוח

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

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

התוצאה התפעולית

בעל העסק יכול להתאים את Sapphire I.C.D.S. לתשתית הקיימת ולהימנע משינוי מיומנויות מיותר. שכבת הנתונים המשותפת מונעת קישור ישיר של מודולים עסקיים לדרייבר. ניבי SQL נפרדים הופכים את ההבדלים לגלויים ולניתנים לבדיקה.

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