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

היי הבר!

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

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

המאמר נכתב על סמך שאלה אחת, ניתן ב-Stack Overflow.

דיונים מעניינים על reddit בקטעים /r/java и / r / תכנות.

יצירת קוד

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

	for (Record2<String, String> record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на 
//   основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT 
 
       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ сгенерированные имена
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

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

יצירת קוד מקור

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

יש הרבה מחוללי קוד כאלה. לדוגמה, XJC יכול ליצור קוד Java מבוסס על קבצי XSD או WSDL. העיקרון תמיד זהה:

• יש אמת מסוימת (פנימית או חיצונית) - למשל מפרט, מודל נתונים וכו'.
• אנחנו צריכים ייצוג מקומי של האמת הזו בשפת התכנות שלנו.

יתרה מכך, כמעט תמיד כדאי לייצר ייצוג כזה – כדי למנוע יתירות.

ספקי סוגים ועיבוד הערות

הערה: גישה נוספת, מודרנית וספציפית יותר ליצירת קוד עבור jOOQ כוללת שימוש בספקי סוגים, כפי שהם מיושמים ב-F#. במקרה זה, הקוד נוצר על ידי המהדר, למעשה בשלב הקומפילציה. באופן עקרוני, קוד כזה אינו קיים בצורה של קודי מקור. בג'אווה יש כלים דומים, אם כי לא אלגנטיים - אלה הם מעבדי הערות, למשל, Lombok.

במובן מסוים, קורים כאן אותם דברים כמו במקרה הראשון, מלבד:

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

מה הבעיה ביצירת קוד?

בנוסף לשאלה המסובכת איך עדיף להתחיל יצירת קוד – ידנית או אוטומטית, אני חייב לציין שיש אנשים שמאמינים שאין צורך ביצירת קוד כלל. ההצדקה לנקודת המבט הזו, שבה נתקלתי לרוב, היא שקשה אז להקים את צינור הבנייה. כן, זה ממש קשה. ישנן עלויות תשתית נוספות. אם אתה רק התחלת עם מוצר מסוים (בין אם זה jOOQ, או JAXB, או Hibernate וכו'), לוקח זמן להגדיר שולחן עבודה שאתה רוצה להשקיע בלימוד ה-API עצמו כדי להפיק ממנו ערך .

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

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

מקורי, אלן או'רורק, ערימת קהל

אבל במצב Hibernate / JPA, זה כל כך קל לכתוב קוד Java.

בֶּאֱמֶת. עבור Hibernate והמשתמשים שלה, זו גם ברכה וגם קללה. במצב Hibernate, אתה יכול פשוט לכתוב כמה ישויות, כמו זה:

	@Entity
class Book {
  @Id
  int id;
  String title;
}

וכמעט הכל מוכן. עכשיו החלק של Hibernate הוא לייצר "פרטים" מורכבים של איך בדיוק הישות הזו תוגדר ב-DDL של ה"דיאלקט" שלך של SQL:

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

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

עם זאת, תן לי. שיקרתי.

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

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

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

מגניב. לְהִתְחַדֵשׁ. שוב, במקרה זה, זה יהיה קל מאוד בהתחלה.

אבל תצטרך לשלם על זה מאוחר יותר.

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

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

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

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

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

קודם כל מסד נתונים

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

וזה לא הכל. לדוגמה, באמצעות Oracle, סביר להניח שתרצה לציין:

• באיזה חלל שולחני נמצא השולחן שלך
• מה הערך שלה PCTFREE
• מה גודל המטמון ברצף שלך (מאחורי המזהה)

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

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

מה לגבי מודל הלקוח?

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

כל מסדי הנתונים מספקים את המטא-מידע שלהם באמצעות SQL. הנה איך לקבל את כל הטבלאות בניבי SQL שונים ממסד הנתונים שלך:

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
 
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
 
-- Oracle
SELECT owner, table_name
FROM all_tables
 
-- SQLite
SELECT name
FROM sqlite_master
 
-- Teradata
SELECT databasename, tablename
FROM dbc.tables

שאילתות אלה (או דומות, תלוי אם אתה צריך לשקול גם תצוגות, תצוגות ממומשות, פונקציות בעלות ערך טבלה) מבוצעות גם על ידי קריאה DatabaseMetaData.getTables() מ-JDBC, או באמצעות מטא מודול jOOQ.

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

• אם אתה משתמש ב-JDBC או ב-Spring, תוכל ליצור קבוצה של קבועי מחרוזת
• אם אתה משתמש ב-JPA, אז אתה יכול ליצור את הישויות עצמן
• אם אתה משתמש ב-jOOQ אתה יכול ליצור מטא מודל jOOQ

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

כעת כל תוספת של מסד נתונים תעדכן אוטומטית את קוד הלקוח. דמיינו למשל:

ALTER TABLE book RENAME COLUMN title TO book_title;

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

@Entity
@Table(name = "book", indexes = {
 
  // Вы об этом задумывались?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

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

האמת היחידה

לא משנה באיזו טכנולוגיה אתה משתמש, תמיד יש מודל אחד שהוא מקור האמת היחיד עבור תת-מערכת כלשהי - או לפחות עלינו לשאוף לכך ולהימנע מבלבול ארגוני שבו "האמת" נמצאת בכל מקום ובשום מקום בבת אחת. הכל יכול להיות הרבה יותר קל. אם אתה רק מחליף קבצי XML עם מערכת אחרת, פשוט השתמש ב-XSD. תסתכל על מטא-מודל INFORMATION_SCHEMA של jOOQ בצורת XML:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD מובן היטב
• XSD מסמן היטב תוכן XML ומאפשר אימות בכל שפות הלקוח
• XSD הוא בעל גרסה טובה ותואם מאוד לאחור
• ניתן לתרגם XSD לקוד Java באמצעות XJC

הנקודה האחרונה חשובה. בעת תקשורת עם מערכת חיצונית באמצעות הודעות XML, אנו רוצים להיות בטוחים שההודעות שלנו תקפות. קל מאוד להשיג זאת עם JAXB, XJC ו-XSD. זה יהיה טירוף גמור לחשוב שבגישת עיצוב של Java, שבה אנו יוצרים את המסרים שלנו כאובייקטי Java, הם יכולים איכשהו להיות מובנים ל-XML ולשלוח אותם לצריכה למערכת אחרת. ה-XML שנוצר בדרך זו יהיה באיכות ירודה מאוד, לא מתועד וקשה לפיתוח. אם הייתה הסכמה על רמת איכות השירות (SLA) על ממשק כזה, מיד היינו מפשלים.

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

מאגרי מידע: הם זהים

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

כאשר עדכון המקור התרחש, כל הלקוחות חייבים גם לעדכן את העותקים שלהם של המודל. ייתכן שחלק מהלקוחות ייכתבו ב-Java באמצעות jOOQ ו-Hibernate או JDBC (או שניהם). לקוחות אחרים עשויים להיכתב ב-Perl (בואו נאחל להם בהצלחה), אחרים ב-C#. זה לא משנה. המודל העיקרי נמצא במסד הנתונים. מודלים שנוצרו על ידי ORM הם בדרך כלל באיכות ירודה, מתועדים בצורה גרועה וקשים לפיתוח.

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

אל תודו לי עדיין, מאוחר יותר.

הבהרה

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

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

חריגים

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

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

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

מקור: www.habr.com