עיצוב אדריכלות 4D: מדריך שלם

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

נקודות חשובות

• עיצוב ארכיטקטורת 4D מפריד בין שלושה היבטים: מודל הנתונים (טבלאות, שדות, יחסים), שכבת ההיגיון העסקי (שיטות, מחלקות, טריגרים) ושכבת ההצגה (טפסים, תיבות רשימה, דיאלוגים).
• סוג היחסים חשוב יותר ממספר הטבלאות: קישור רבים-לרבים זקוק לטבלת צומת, בעוד שקישור אחד לרבים משתמש בשדה מפתח זר בתוספת קשר.
• אינדקסים מאיצים קריאה אך מאטים כתיבה - אינדקס מפתחות זרים וכל שדה המשמש בסעיף WHERE של שאילתה, לא בכל שדה.
• שכבת ה-ORDA (גישה ל-Object Relational Data Access) של 4D משנה את אופן החשיבה על סכימה: טבלאות ושדות בעלי שמות טובים הופכים לשמות קריאים של מחלקות נתונים ושמות תכונות בקוד.
• שרת לקוח לעומת פריסה של משתמש יחיד היא החלטה ארכיטקטונית, לא מחשבה שלאחר הפריסה - היא משפיעה על נעילה, שמירה במטמון ואיך אתה כותב שאילתות.
• קונבנציות מתן שמות מיושמות באופן עקבי מהיום הראשון חוסכות יותר זמן רה-פקטורינג (refactoring) מכל הרגל בודד אחר.

מה המשמעות של “ארכיטקטורת 4D” בהקשר של מסד נתונים

עיצוב ארכיטקטורת 4D מתייחס לתכנון המבני של אפליקציה שנבנתה על פלטפורמת 4D (4th Dimension), מסד הנתונים היחסי וסביבת הפיתוח low-code ששוחררו במקור על ידי הצוות של Laurent Ribardière ב-1984 וכעת מתוחזקים על ידי 4D SAS. שלא כמו מסד נתונים SQL טהור, 4D מאגד את מנוע הנתונים, שפת תכנות, מעצב טפסים ושרת אינטרנט/REST למוצר אחד - כך שה”ארכיטקטורה” כאן משתרעת הן על הסכימה והן על שכבות היישום שיושבות עליה.

המונח מבולבל לפעמים עם הדמיה אדריכלית (4D BIM, זמן כממד הרביעי בתכנון מבנים). מדריך זה מכסה את המשמעות התוכנתיות: כיצד לפרוס מסד נתונים 4D ושכבות היישום שלו. אם הגעת לחפש עיצוב בניין, המושגים שלהלן לא יחולו.

שלוש השכבות של יישום 4D

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

שכבה 1 - מודל הנתונים

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

שכבה 2 — לוגיקה עסקית

ההיגיון העסקי חי בשיטות פרויקטים, שיעורים וטריגרים של טבלאות. ב-4D המודרני, מחלקות (הוצגו עם 4D v18 R3 והורחבו מאז) מאפשרות לך לכתוב קוד לשימוש חוזר וניתן לבדיקה במקום לפזר לוגיקה על פני שיטות טופס. טריגר בטבלה מופעל על יצירה, שמירה ומחיקה - שימושי עבור מסלולי ביקורת, אך טריגר שקורא לממשק המשתמש יישבר בהקשרי שרת headless.

קשורים: Claris FileMaker Pro — פלטפורמת מסד הנתונים הרלוונטיים ארוכת השנים לצוותים שזקוקים לאפליקציות מותאמות אישית במחשב שולחני, באינטרנט ובנייד מקובץ בודד..

שכבה 3 — מצגת

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

עיצוב מודל הנתונים: טבלאות, יחסים ומפתחות

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

בחירת פירוט טבלה

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

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

סוגי קשרים

4D תומך בקשרים אוטומטיים המוגדרים בעורך המבנה וביחסים ידניים שנוצרו בקוד. הדפוסים הנפוצים:

קשר	יישום 4D	שימוש אופייני
אחד לרבים	שדה מפתח זר בצד “רבים” בתוספת יחס	חשבונית → שורות חשבונית
רבים-לרבים	טבלת צומת עם שני מפתחות זרים	מוצרים ↔ ספקים
אחד לאחד	מפתח ראשי משותף או מפתח זר ייחודי	משתמש → פרופיל משתמש
הפניה עצמית	מפתח זר המצביע חזרה לאותה טבלה	עובד → מנהל

אסטרטגיית מפתח ראשית

4D מציע מפתחות ראשיים בעלי אורך אורך אוטומטי ומפתחות ראשיים UUID (טקסט). מקשי Longint הם קומפקטיים ומהירים לאינדקס; UUIDs הם ייחודיים בעולם, מה שחשוב בעת מיזוג נתונים ממספר אתרים או סנכרון עם מערכות חיצוניות. פשרה נפוצה היא מפתח פנימי ארוך בתוספת שדה טקסט ייחודי נפרד “הפניה חיצונית”.

יצירת אינדקס וביצועי שאילתות

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

מה לאינדקס

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

מה לא לאינדקס

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

אסטרטגיית שאילתות

שאילתות ORDA (ds.Invoice.query("Status = :1"; "Open")) עדיפות בדרך כלל על פני פקודות QUERY קלאסיות עבור קוד חדש מכיוון שהן מחזירות בחירות ישויות שניתן למיין, לסנן ולהעביר בין שיטות ללא שאילתה מחדש. עבור טבלאות גדולות מאוד, הגבלת השאילתה עם קריטריונים שנוספו לאינדקס לפני החלת מסננים שאינם מותאמים לאינדקס שומרת על זמני תגובה צפויים.

קשורים: Knack — בונה מסדי נתונים ללא קוד המיועד לפורטלים, ספריות וכלים פנימיים - עם תמחור קבוע במקום עמלות למשתמש..

ORDA וארכיטקטורת 4D מודרנית

ORDA (Object Relational Data Access) היא שכבת הגישה לנתונים מונחה עצמים של 4D, שהוצגה ב-4D v17. הוא חושף טבלאות כמחלקות נתונים ורשומות כישות, כך שטבלה בשם חשבונית הופכת ל-ds.Invoice ושדה בשם TotalNet הופך ל$invoice.TotalNet.

יש לכך השלכה ארכיטקטונית עבור עיצוב ארכיטקטורת 4D: שמות טבלאות ושדות הם כעת חלק מהממשק ה-API הציבורי שלך. שינוי שם של שדה שובר קוד באופן שנראה בזמן ההידור, אך מתן שמות לא עקבי מקשה על קריאת קוד ORDA. אימוץ מוסכמה - שמות טבלה יחידים, שדות PascalCase, ללא קיצורים - משתלם מיד.

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

חביב הקוראים: Microsoft Power Apps — פיתוח אפליקציות בעלות קוד נמוך ברמה ארגונית מחוברת ל-Microsoft 365, Dataverse ו-Power Automate..

פריסת שרת לקוח, משתמש יחיד ואינטרנט

טופולוגיית הפריסה מעצבת את עיצוב ארכיטקטורת ה-4D יותר ממה שמפתחים רבים מצפים.

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

שרת-לקוח מפצל את שרת ה-4D (מנוע נתונים) מ-4D Client (ממשק). הרשומות ננעלות בשרת, ועלות הרשת הלוך ושוב של כל שאילתה הופכת משמעותית. ארכיטקטורות שמנפיקות שאילתות קטנות רבות לכל מסך מתפקדות כאן בצורה גרועה; שאילתות אצווה ושימוש בבחירות ישויות מפחית נסיעות הלוך ושוב.

פריסה של אינטרנט ו-REST חושפת את אותו מודל נתונים דרך שרת ה-REST של 4D או באמצעות שיטות רשת מקופלות. האבטחה עוברת לקדמת הבמה: יש להגביל את הגישה לטבלה ולשדה באמצעות תפקידים והרשאות, וכל כלל עסקי שנאכף רק בשיטת טופס אינו נאכף למעשה עבור לקוחות אינטרנט.

מוסכמות שמות ותיעוד

מתן שמות עקבי אינו זוהר אך מכריע עבור עיצוב אדריכלות 4D. מוסכמה בר ביצוע עבור 4D:

• טבלאות: שמות עצם בודדים, PascalCase (“לקוח”, “InvoiceLine”).
• שדות: PascalCase, ללא קידומות סוג (“InvoiceDate”, לא “dInvDate”).
• מערכות יחסים: נקראות לפי טבלת היעד (“חשבוניות_לקוח”).
• שיטות: פועל ראשון (“CreateInvoice”, “RecalculateTotals”).
• שיעורים: שם עצם ראשון (“InvoiceService”, “Tax Calculator”).

תיעוד הסכימה - אפילו כקובץ Markdown יחיד המפרט כל טבלה, מטרתה ויחסי המפתח שלה - מקל בהרבה על ההעברה וההגירות העתידיות. עורך המבנה של 4D מציג יחסים בצורה גרפית, אבל הוא לא מסביר מדוע קיימת טבלה.

טעויות נפוצות בעיצוב אדריכלות 4D

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

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

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

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

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

כיצד להחליט: רשימת בדיקה מעשית

לפני בניית עיצוב ארכיטקטורת 4D שלך, עבד על השאלות הבאות:

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

תשובות לשש שאלות אלו קובעות את רוב ההחלטות המבניות בפרויקט 4D.

קריאה נוספת

התיעוד הרשמי של 4D ב-Developer.4d.com מכסה ORDA, מחלקות, הרשאות ופריסה בפירוט. לעקרונות היסודות של מודלים יחסיים החלים ללא קשר לפלטפורמה, עיין במאמר בוויקיפדיה על נורמליזציה של מסדי נתונים. להקשר הרחב יותר של פלטפורמות לפיתוח יישומים דל קוד, הערך בוויקיפדיה על פלטפורמות פיתוח בעלות קוד נמוך הוא נקודת התחלה סבירה. 4D SAS מפרסמת גם הערות מהדורה ומדריכי הגירה המתארים מתי ORDA, מחלקות ותכונות עיצוב אחרות של ארכיטקטורת 4D הוצגו.

שאלות נפוצות

מהו עיצוב ארכיטקטורת 4D?

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

האם ארכיטקטורת 4D זהה ל-4D BIM?

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

האם עלי להשתמש בפקודות ORDA או 4D קלאסיות?

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

כמה אינדקסים צריכים להיות לטבלה 4D?

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

באיזה סוג מפתח ראשי עלי לבחור ב-4D?

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

האם אוכל לשנות את מודל הנתונים ה-4D לאחר הפריסה?

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