ב Rails יצרתי טבלה בבסיס הנתונים עם קוד שנראה בערך כך:
create_table :users do |t|
t.string :username
t.string :email
t.timestamps
end
את הקוד הזה אפשר להפעיל מול כל בסיס נתונים וריילס כבר יבין לבד מה לעשות ואיך להתאים בין string ו timestamps לסוגי הנתונים של בסיס הנתונים הספציפי שבחרתם. גם סיקוולייז של node עובדת בצורה דומה
ב Sequelize הממשק דורש יותר קוד אבל עדיין הספריה מטפלת בהבדלים בין בסיסי נתונים:
'use strict';
module.exports = {
up: async (queryInterface, Sequelize) => {
await queryInterface.createTable('Users', {
id: {
type: Sequelize.INTEGER,
autoIncrement: true,
primaryKey: true,
allowNull: false
},
username: {
type: Sequelize.STRING,
allowNull: false
},
email: {
type: Sequelize.STRING,
allowNull: false
},
createdAt: {
type: Sequelize.DATE,
allowNull: false,
defaultValue: Sequelize.NOW
},
updatedAt: {
type: Sequelize.DATE,
allowNull: false,
defaultValue: Sequelize.NOW
}
});
},
down: async (queryInterface, Sequelize) => {
await queryInterface.dropTable('Users');
}
};
ספריות בסיסי נתונים מודרניות יותר לוקחות גישה שונה. זו דוגמה מהתיעוד של דריזל ליצירת טבלה:
export const users = mysqlTable('users', {
id: bigint('id', { mode: 'number' }).primaryKey().autoincrement(),
fullName: varchar('full_name', { length: 256 }),
}, (users) => ({
nameIdx: index('name_idx').on(users.fullName),
}));
וזו מיגרציה בקיסלי שכתובה בצורה מפורשת עבור Postgresql:
await db.schema
.createTable('person')
.addColumn('id', 'serial', (col) => col.primaryKey())
.addColumn('first_name', 'varchar', (col) => col.notNull())
.addColumn('last_name', 'varchar')
.addColumn('gender', 'varchar(50)', (col) => col.notNull())
.addColumn('created_at', 'timestamp', (col) =>
col.defaultTo(sql`now()`).notNull(),
)
.execute()
למה הם עושים את זה? ומה עדיף?
יש שני יתרונות לספריה שלא מטפלת בהבדלים בין בסיסי נתונים - הראשון הוא גודל הספריה, או יותר נכון הקוטן שלה. ספריה שצריכה לעשות פחות תהיה יותר קטנה, קלה יותר לתחזוקה ופיתוח ותוכל לאמץ פיצ'רים חדשים מהר יותר. אני מודה שאם אני הייתי כותב ספריית גישה לבסיס נתונים גם הייתי מעדיף לוותר על הקוד שמטפל בהבדלים בין בסיסי הנתונים ולחסוך המון כאב ראש.
היתרון השני הוא השליטה שספריה כזאת יכולה לאפשר למתכנתים - שבגלל שעכשיו כותבים קוד ספציפי לבסיס נתונים יכולים להרגיש יותר בנוח להשתמש ביכולת מתקדמות יותר של בסיס נתונים ספציפי, לדוגמה אם אנחנו יודעים שאנחנו עובדים בפוסטגרס נוכל להשתמש בכל הפונקציות של פוסטגרס לעבודה עם JSON-ים.
השאלה הפתוחה כאן היא באיזו מידה אנחנו צריכים או משתמשים באותו קוד ספריה שמטפל בהבדלים בין בסיסי נתונים, או האם בכלל אפשר לדמיין להחליף בסיס נתונים ושכל הקוד פשוט ימשיך לעבוד. לדעתי היכולת להחליף בסיסי נתונים יכולה לעזור בתחילת הפיתוח אם אנחנו עדיין לא בטוחים איזה בסיס נתונים יהיה הטוב ביותר עבור הפרויקט, אבל ככל שהפיתוח מתקדם מהר מאוד אנחנו משלבים ממילא יכולות ספציפיות של בסיס נתונים ומאבדים את היכולת לעבור. יש סיכוי מאוד נמוך שמישהו ירצה לקחת פרויקט פרודקשן ולהעביר אותו לבסיס נתונים מסוג אחר.
אנחנו כן כמפתחים עובדים על מספר פרויקטים ופרויקטים שונים כן עובדים על בסיסי נתונים שונים, לכן מפתחי Rails יכולים לעבור בין פרויקט Rails שמתחבר ל MySQL לפרויקט ריילס שמתחבר לפוסטגרס ולהשתמש בידע שלהם בריילס כדי לתחזק ולפתח את המערכת, כמעט בלי שיצטרכו ללמוד דברים חדשים.
מה דעתכם? יצא לכם להעביר פרויקט בין בסיסי נתונים, או לעבוד באותו זמן על פרויקטים שמתחברים לבסיסי נתונים מסוגים שונים? כמה חשוב לכם שספריית בסיסי הנתונים שלכם תעבוד בצורה זהה בין בסיסי הנתונים השונים ותסתיר מכם את ההבדלים ביניהם?
