SQLite on Dev TLDRLSS

لا تنخدع بعفوية SQLite! ما هي فخاخ الأنواع الديناميكية؟ ولماذا ALTER TABLE غير مكتمل؟ وكيف تبني بنية برمجية دفاعية في Node.js لترقية مخطط الجدول بدون ألم؟

Tue, 19 May 2026 18:10:00 +0800

تخيل سلة إعادة تدوير وضعت عليها بوضوح ملصقًا يقول "للزجاجات البلاستيكية فقط"، ولكن عندما يلقي شخص ما قطعة ورق داخلها، فإنها تقبلها بصمت دون كلمة احتجاج واحدة؟

هذه هي التجربة المثيرة للقشعريرة التي يمر بها المطورون عندما يقابلون نظام أنواع SQLite لأول مرة.

إذا كنت معتادًا على أسلوب موظف الجمارك الصارم في PostgreSQL (حيث يتم رفض الأنواع غير الصحيحة مباشرة من الدخول)، فإن عفوية وسهولة SQLite قد تجعلك تشك في حياتك.

والأكثر رعبًا من ذلك، عندما تريد تعديل بنية جدول، ستخبرك قاعدة البيانات بالتالي:

"لا يمكن تعديل الجدول مباشرة. يرجى بناء منزل جديد، ونقل الأثاث إليه، ثم تفجير المنزل القديم."

تحت الغطاء، تمتلك SQLite 5 فئات تخزين فقط

بغض النظر عن أسماء الأنواع الفخمة التي تعلن عنها في CREATE TABLE مثل (VARCHAR(255)، BIGINT، DECIMAL)، فإن SQLite تحت الغطاء لا تتعرف إلا على فئات التخزين الخمس التالية:

فئة التخزين	الوصف
NULL	قيمة فارغة
INTEGER	عدد صحيح (يشغل تلقائيًا من 1 إلى 8 بايت اعتمادًا على حجم القيمة)
REAL	رقم عشري عائم (ثابت 8 بايت)
TEXT	سلسلة نصية (ترميز UTF-8 افتراضي)
BLOB	كائن ثنائي كبير (يتم تخزينه تمامًا كما تم إدخاله)

الأنواع التي تحددها في الأعمدة هي مجرد "توصية" لـ SQLite وليست "قواعد إلزامية".

يطلق على هذا اسم "Type Affinity" (أفيونيتي النوع). ستحاول SQLite تحويل بياناتك إلى النوع الموصى به، ولكن إذا لم تتمكن من ذلك، فستقوم بإدخال البيانات الأصلية على أي حال دون إظهار أي خطأ.

يمكنك الإعلان عن عمود age INTEGER في SQLite ثم إدخال السلسلة النصية 'ثمانية عشر عامًا للأبد'؛ وسوف تقبله بكل سرور.

ثلاثة فخاخ أنواع هي الأسهل في الوقوع بها

الفخ 1: غياب نوع Boolean الأصلي

لا تحتوي SQLite على نوع boolean أصلي. يمكن تمثيل قيمتي True و False بالأعداد الصحيحة 1 و 0 فقط.

عندما تسترجع البيانات من SQLite باستخدام Node.js، ستحصل على الرقم 1 أو 0 وليس true أو false.

إذا قمت مباشرة بإجراء فحص مثل if (user.is_admin === true)، فلن يكون صحيحًا أبدًا.

الفخ 2: غياب نوع Date/Time

لا تحتوي SQLite على نوع للتاريخ/الوقت. لا يمكنك تخزين الوقت إلا بالطرق التالية:

طريقة التخزين	مثال	الميزات والعيوب
TEXT (سلسلة ISO-8601)	`'2026-05-19T18:00:00Z'`	الأكثر توصية، وضوح عالٍ، وتحويل سلس عند الانتقال إلى PostgreSQL مستقبلاً
INTEGER (طابع Unix الزمني)	`1747656000`	يشغل مساحة صغيرة، ولكنه غير مقروء للبشر

لا تخزن التواريخ مطلقًا بتنسيقات مخصصة عشوائية مثل 19/5/2026 6:00 مساءً، وإلا فسيكون ترحيل البيانات مستقبلاً كارثة حقيقية.

الفخ 3: إدخال سلسلة نصية في عمود INTEGER لن يؤدي لحدوث خطأ

في PostgreSQL يؤدي إدخال سلسلة نصية في عمود INTEGER إلى حدوث خطأ على الفور. ولكن SQLite ستحاول التحويل بصمت فقط، وعند الفشل، ستقبل البيانات كما هي.

هذا يعني أن البيانات الملوثة قد تتسلل بصمت إلى قاعدة بياناتك حتى يأتي يوم يتوقف فيه برنامجك فجأة بسبب تلقي نوع غير متوقع، وعندها فقط تكتشف المشكلة.

البرمجة الدفاعية: مواجهة قاعدة بيانات عفوية بموقف صارم

في مواجهة عفوية وسهولة SQLite، يجب عليك بناء آليات دفاع صارمة في تطوير تطبيقات Node.js:

مستوى الدفاع	الأداة	الدور
حارس وقت الترجمة	TypeScript	التقاط الأنواع غير الصحيحة في مرحلة كتابة الكود
التحقق من مدخلات API	Zod	التحقق من صحة البيانات الواردة بصرامة (ضمان أن يكون age رقمًا دائمًا)
تحويل الأنواع الداخلي	Prisma / Drizzle ORM	معالجة فروق الأنواع تلقائيًا بين SQLite و PostgreSQL

إن نقل "حارس بوابة التحقق من البيانات" من مستوى قاعدة البيانات إلى مستوى تطبيق Node.js هو استراتيجية رئيسية للاستفادة من سرعة تطوير SQLite مع ضمان قابلية التوسع مستقبلاً.

عند استخدام ORM، طالما أنك تعلن عن type: 'boolean' في كودك، فإن الـ ORM يقوم تلقائيًا بتحويله إلى 1/0 عند الحفظ في SQLite ويحوله مجددًا إلى true/false عند القراءة، مما يخفي فروق الأنواع الأساسية تمامًا.

ALTER TABLE غير مكتمل: ما يمكن وما لا يمكن تعديله

دعم SQLite لتعديل بنية الجداول محدود للغاية:

العملية	مدعومة
إضافة عمود (`ADD COLUMN`)	نعم
إعادة تسمية عمود (`RENAME COLUMN`)	نعم
حذف عمود (`DROP COLUMN`)	نعم (في الإصدارات الحديثة)
إعادة تسمية جدول (`RENAME TO`)	نعم
تغيير نوع العمود	لا
إضافة/إزالة قيود `UNIQUE` و `NOT NULL`	لا
تعديل المفتاح الأساسي	لا
تعديل المفتاح الأجنبي	لا

بمجرد أن تحتاج إلى إجراء أي من التعديلات "غير المدعومة"، تتطلب منك SQLite تنفيذ استراتيجية "إعادة الإنشاء والنقل".

أربع خطوات لإعادة الإنشاء والنقل: طريقة ترقية جداول SQLite

نظرًا لعدم إمكانية التعديل المباشر، فإن الطريقة القياسية الموصى بها في الوثائق الرسمية هي بناء منزل جديد، ونقل الأثاث، وتفجير المنزل القديم، وتعليق اللوحة الجديدة:

الخطوة	الإجراء	الوصف
1	إنشاء جدول جديد	إنشاء `CREATE TABLE users_new (...)` بالبنية الصحيحة
2	نسخ البيانات	`INSERT INTO users_new SELECT ... FROM users`
3	حذف الجدول القديم	`DROP TABLE users`
4	إعادة تسمية الجدول	`ALTER TABLE users_new RENAME TO users`

يجب تنفيذ هذه الخطوات الأربع دفعة واحدة ومن دون انقطاع؛ أي انقطاع في الطاقة أو تعطل للتطبيق في منتصف الطريق سيؤدي إلى فقدان البيانات.

ضمان عدم فقدان البيانات أثناء الترقية: خطان للدفاع عن الأمان

خط الدفاع 1: الدفاع المادي، نسخ الملف مباشرة

تعتبر SQLite في جوهرها مجرد ملف واحد. قبل تنفيذ أي تغييرات في المخطط، يكفي ببساطة نسخ ملف .db ليكون نسخة احتياطية.

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

إذا سارت الأمور بشكل سيء، فإن استبدال الملف يستعيد كل شيء في لمحة بصر. هذه ميزة لا توفرها قواعد البيانات الكبيرة الأخرى.

خط الدفاع 2: تغليف المعاملة (Transaction), آلة الزمن لقاعدة البيانات

قم بتغليف جميع خطوات الترحيل داخل معاملة Transaction واحدة؛ وإذا فشلت أي خطوة، فسيتم التراجع تلقائيًا (Rollback) عن العملية بأكملها وكأن شيئًا لم يكن.

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('اكتملت ترقية الجدول');
} catch (error) {
  console.error('فشلت الترقية، تم استعادة البيانات بأمان:', error.message);
}

"ملف النسخ الاحتياطي + ربط المعاملة" هو الوسادة الهوائية لترحيل قاعدة بياناتك.

التحكم في عفوية SQLite بموقف صارم

تحكم في عفوية وسهولة SQLite باستخدام بنية صارمة لطبقة التطبيق للاستمتاع بميزة سرعة التطوير الفائقة مع تجنب الديون التقنية مستقبلاً.

يعتبر نظام الأنواع في SQLite مرنًا وعفويًا للغاية، كما أن ALTER TABLE لديه العديد من القيود.

ولكن طالما أنك تقوم بتطبيق فحص أنواع TypeScript + تحقق Zod + تجريد الـ ORM في جهة Node.js بجدية، وتدمج ذلك مع استراتيجية الأمان المتمثلة في النسخ الاحتياطي المادي + المعاملات الصارمة، فيمكنك الاستمتاع بكفاءة التطوير الرائعة التي توفرها SQLite مع تمهيد الطريق للانتقال السلس إلى PostgreSQL مستقبلاً.

Reference

لا تستخدم PostgreSQL لكل شيء! ما هي مزايا البنية المدمجة والتهيئة الصفرية لـ SQLite؟ أين تكمن حدود SQLite؟ متى يجب اختيار SQLite ومتى يجب اختيار PostgreSQL؟

Tue, 19 May 2026 18:00:00 +0800

هل فكرت يوماً في حقيقة أن المتصفح الذي تفتحه يومياً، وتطبيق المراسلة على هاتفك، وحتى أداة تدوين الملاحظات على سطح مكتبك، كلها تخفي قاعدة البيانات الخفيفة نفسها؟

إنها لا تتطلب منك تثبيت أي برنامج خادم، ولا تحتاج إلى إعدادات حساب أو كلمة مرور، بل ولا تحتاج حتى إلى اتصال بالإنترنت. إنها ببساطة ملف واحد، يستقر بهدوء على القرص الصلب الخاص بك، وجاهز لخدمتك في أي وقت.

هذا الوجود الهادئ هو SQLite.

ما هي SQLite؟ قاعدة البيانات الأكثر انتشاراً في العالم

SQLite هي محرك قاعدة بيانات علاقة مدمجة مكتوبة بلغة C.

ليس لديها عملية خادم مستقلة، بل يتم دمجها مباشرة داخل تطبيقك لتعمل.

هذا يختلف تماماً عن PostgreSQL أو MySQL التي قد تكون معتاداً عليها. قواعد البيانات التقليدية هي خوادم مستقلة تعمل بشكل منفصل، ويجب على برنامجك “التواصل” معها عبر بروتوكول شبكة (TCP/IP).

But SQLite مختلفة؛ فهي مجرد كتلة من الكود، تعمل مباشرة داخل تطبيقك، وتقوم بالقراءة والكتابة في ملف .db هذا على القرص الصلب الخاص بك.

وجه المقارنة	SQLite (مدمجة)	PostgreSQL (عميل-خادم)
وضع التشغيل	مدمجة مباشرة في التطبيق، بدون خادم مستقل	عملية خادم مستقلة، عبر اتصال الشبكة
التهيئة والإعداد	تهيئة صفرية، بدون تثبيت، بدون بيانات اعتماد	تتطلب تثبيتاً، وإعداد حساب/كلمة مرور وجدار حماية
تخزين البيانات	ملف واحد متوافق مع جميع الأنظمة	ملفات متعددة تحت دليل الخادم
طريقة النسخ الاحتياطي	نسخ هذا الملف مباشرة	تتطلب أدوات مخصصة مثل pg_dump

وبسبب هذه الميزة المتمثلة في “التوصيل والتشغيل المباشر”، أصبحت SQLite محرك قاعدة البيانات الأكثر تثبيتاً واستخداماً في العالم.

من أنظمة تشغيل Android و iOS، ومتصفحات Chrome و Firefox، إلى Adobe Lightroom و WhatsApp وحتى نظام الطيران في طائرات Airbus A350، فهي موجودة في كل مكان.

استخدام SQLite في Node.js

إذا كنت مطور Node.js، فإن استخدام SQLite سهل للغاية. لا تحتاج إلى تثبيت أي برنامج خادم لقاعدة البيانات على جهاز الكمبيوتر الخاص بك، بل تحتاج فقط إلى تثبيت حزمة npm للبدء.

الخيارات الأكثر استخداماً في المجال اليوم:

اسم الحزمة	الميزات	السيناريو الموصى به
`sqlite3`	الأكثر عراقة، تدعم واجهات برمجة التطبيقات غير المتزامنة	عندما تحتاج إلى معالجة العديد من المهام غير المتزامنة معاً
`better-sqlite3`	أداء ممتاز، تصميم بديهي لواجهة البرمجة، سريعة للغاية	التوصية الأولى، لزيادة كفاءة التطوير وسرعة التنفيذ

إنشاء قاعدة بيانات والاستعلام عنها باستخدام better-sqlite3 يستغرق أقل من خمس دقائق:

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

إذا كان الملف غير موجود، ستقوم better-sqlite3 بإنشائه تلقائياً لك.

تدعم SQLite قواعد SQL أقوى مما تظن

يعتقد الكثير من الناس أن SQLite بسيطة للغاية، ولكنها في الواقع تدعم معظم قواعد SQL القياسية، بما في ذلك العديد من الميزات المتقدمة:

فئة القواعد	العناصر المدعومة
العمليات الأساسية	`SELECT`, `INSERT`, `UPDATE`, `DELETE`
تعريف البيانات	`CREATE TABLE`, `CREATE INDEX`, `CREATE VIEW`
الاستعلام المتقدم	`WITH` (الاستعلام التكراري CTEs)، وظائف النافذة (Window Functions)
معالجة التعارض	`UPSERT` (`INSERT ... ON CONFLICT DO UPDATE`)
معالجة JSON	وظائف مدمجة مثل `json_extract`, `json_array`, `json_object` وغيرها
التحكم في العمليات	`BEGIN`, `COMMIT`, `ROLLBACK`, `SAVEPOINT`
استعلام الربط	`INNER JOIN`, `LEFT JOIN`, `RIGHT JOIN`, و `FULL OUTER JOIN`

الفلسفة الأساسية لـ SQLite هي “صغير وجميل”، حيث تدعم معظم ميزات SQL التي تحتاجها يومياً مع الحفاظ على خفة وزنها الفائقة.

أين تكمن حدود SQLite؟

خفة الوزن لها ثمنها. إذا قارنا SQLite بـ متجر بقالة عصري يحتوي على ممر دفع واحد فقط، فإن PostgreSQL هي متجر Costco مجهز بـ 50 صندوق محاسبة.

1. ازدحام عمليات الكتابة

عندما تقوم SQLite بكتابة البيانات، فإنها تقفل ملف قاعدة البيانات بأكمله.

تخيل مطعم يحتوي على مرحاض واحد فقط: يمكن لـ 100 شخص النظر إلى قائمة الطعام في الخارج (القراءة) في نفس الوقت، ولكن بمجرد أن يدخل شخص واحد ويغلق الباب (الكتابة)، لا يمكن للآخرين سوى الانتظار في الطابور.

على الرغم من أن تفعيل وضع WAL (Write-Ahead Logging) يمكن أن يحسن أداء القراءة/الكتابة المتزامنة، إلا أنه من الناحية الهيكلية لا يزال غير قادر على تحقيق كتابة متزامنة متعددة الخيوط على صفوف بيانات مختلفة.

2. لا يمكن تشغيلها عبر خوادم متعددة

جوهر SQLite هو ملف مادي. إذا تم نشر نظامك على خوادم متعددة (التوسع الأفقي)، فإن هذه الخوادم لا يمكنها مشاركة نفس الملف بأمان.

3. غياب الإدارة الدقيقة للصلاحيات

لا يوجد في SQLite مفهوم “حسابات المستخدمين”. أي شخص يمكنه قراءة ملف .db على مستوى نظام التشغيل يمكنه عرض وتعديل جميع البيانات.

بالنسبة لـ الأنظمة التجارية التي تتطلب عمليات تدقيق صارمة للبيانات الشخصية، فإن هذا الأمر غير مقبول تماماً.

SQLite مقابل PostgreSQL: اتخاذ قرار اختيار التكنولوجيا

لا توجد أداة جيدة أو سيئة، بل هناك أداة مناسبة أو غير مناسبة. إليك قائمة المراجعة النهائية لمساعدتك في اتخاذ القرار:

السؤال	الإجابة “نعم” ← اختر SQLite	الإجابة “لا” ← اختر PostgreSQL
هل يوجد خادم خلفي واحد فقط، أو يعمل النظام محلياً بالكامل؟	نعم	لا (يتطلب توسعاً أفقياً، خوادم متعددة)
هل سلوك النظام يعتمد بشكل أساسي على القراءة، دون كتابة متزامنة عالية التردد؟	نعم	لا (سيتنافس المستخدمون على الكتابة المتزامنة)
لا تحتاج لصلاحيات حساب قاعدة بيانات دقيقة أو فهارس متقدمة؟	نعم	لا (تعتمد بشكل كبير على الميزات المتقدمة)

مقارنة سيناريوهات أكثر تحديداً:

السيناريو	الخيار الموصى به	السبب
برامج سطح المكتب، تطبيقات الهاتف، أجهزة IoT	SQLite	البيانات تنتقل مع الجهاز، بدون الحاجة لتثبيت
المدونات الشخصية، مواقع العرض التعريفية	SQLite	قراءة كثيرة وكتابة قليلة، توفر تكاليف صيانة الخادم
التطوير السريع للنماذج الأولية، العروض التوضيحية	SQLite	ما عليك سوى إنشاء ملف للبدء فوراً
المنتديات المجتمعية، منصات التجارة الإلكترونية	PostgreSQL	كتابة متزامنة عالية، تتطلب قفل على مستوى الصف
النشر الموزع على خوادم متعددة	PostgreSQL	الحاجة إلى مشاركة مصدر البيانات بين أجهزة مختلفة
الأنظمة الحساسة مثل الطبية والمالية	PostgreSQL	تتطلب تحكماً صارماً في الصلاحيات بناءً على الأدوار

هل قاعدة بياناتك هي مذكرة جيب أم مقسم هاتف مركزي؟

إذا كانت البيانات “جهاز واحد، ثابتة، يملكها شخص واحد”، فاختر SQLite للاستمتاع بخفة الوزن والحرية القصوى؛

إذا كانت البيانات “سحابية، ديناميكية، تفاعلية للغاية”، فدع PostgreSQL تتولى المهمة.

الفلسفة الأساسية لـ SQLite هي “مكون داخلي للتطبيق”، بينما يتموضع PostgreSQL كـ “مركز مستقل للبنية البرمجية للنظام”.

في المرة القادمة التي تتخذ فيها قراراً بشأن البنية الهيكلية، لا تتسرع في استخدام PostgreSQL. اسأل نفسك أولاً:

“هل قاعدة بياناتي هي مذكرة جيب، أم مقسم هاتف مركزي؟”

عندما تصبح الإجابة واضحة، سيظهر الخيار المناسب تلقائياً.