ما هو SQLite؟ شرح قاعدة البيانات المدمجة

SQLite قاعدة بيانات تعيش داخل برنامجك

أغلب قواعد البيانات التي سمعت عنها — MySQL وPostgres وSQL Server — تشتغل كبرنامج مستقل. يجب أن تشغّل خادمًا (server)، يستمع على منفذ معيّن، وتطبيقك يتصل به عبر الشبكة لكي يرسل له الاستعلامات. أما SQLite فيتخلّى عن هذا النموذج بالكامل.

SQLite عبارة عن مكتبة (library)، تربطها مع برنامجك مباشرة، فتحصل على قاعدة بيانات SQL كاملة مخزّنة في ملف واحد على القرص. لا يوجد خادم، ولا منفذ، ولا عملية خلفية (daemon)، ولا أمر pg_ctl start. تطبيقك يفتح ملفًا فقط، وهذا الملف هو قاعدة البيانات نفسها.

sqlite3 mydata.db

هذا الأمر يفتح (أو ينشئ) ملفًا اسمه mydata.db ويعطيك واجهة SQL تفاعلية. كل ما تعمله — جداول، صفوف، فهارس — يُخزَّن داخل هذا الملف الواحد فقط. انسخه إلى جهاز آخر تنتقل معك قاعدة البيانات كاملة، واحذفه تختفي قاعدة البيانات بكل ما فيها.

جولة سريعة في صياغة SQL

صياغة SQL في sqlite لا تختلف عمّا اعتدت عليه في أي قاعدة بيانات أخرى. لو سبق وتعاملت مع MySQL أو PostgreSQL، ستجد أن معظم الأمور مألوفة لك:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

SQL القياسي — CREATE TABLE وINSERT وSELECT وORDER BY. يدعم SQLite الأجزاء التي تستخدمها فعلياً من معيار SQL في عملك اليومي، إضافة إلى مزايا حديثة مثل CTEs ودوال النوافذ (Window Functions) ودوال JSON. أما الفروقات بينه وبين Postgres أو MySQL فتتمحور غالباً حول الأنواع وبعض اختلافات الصياغة البسيطة، وسنتطرّق إليها لاحقاً.

ماذا تعني كلمتا "مدمجة" و"بدون خادم" فعلياً؟

هناك مصطلحان يتكرران باستمرار عند الحديث عن SQLite، ويستحقان التوضيح.

مدمجة (Embedded) تعني أن SQLite يعمل داخل نفس عملية تطبيقك (Process)، فلا توجد عملية منفصلة لقاعدة البيانات. عندما يستدعي سكربت Python مثلاً sqlite3.connect("data.db")، فإن محرّك SQL يعمل داخل عملية Python نفسها، ويقرأ من الملف ويكتب إليه مباشرة.

بدون خادم (Serverless) تعني أنه لا يوجد خادم تحتاج إلى تثبيته أو إعداده أو تشغيله أو تأمينه أو أخذ نسخ احتياطية منه. قارِن بين الخطوات اللازمة للبدء باستخدام قاعدة بيانات:

• Postgres: ثبّت Postgres، شغّل الخدمة، أنشئ مستخدماً، أنشئ قاعدة بيانات، اضبط ملف pg_hba.conf، ثم اتصل عبر TCP.
• SQLite: افتح ملفاً.

هذا هو الفرق كله. قدرات أقل، لكن إجراءات أبسط بكثير.

قاعدة البيانات بأكملها في ملف واحد

هذه النقطة التي تفاجئ كثيراً من الناس. صيغة الملف موثّقة ومستقرّة — ملف بامتداد .db (أو .sqlite أو .sqlite3، فالامتداد مجرد عُرف متّبع) يمكنك:

• إرساله بالبريد الإلكتروني إلى زميل.
• رفعه إلى git (الملفات الصغيرة على الأقل).
• نسخه بأمر cp للحصول على نسخة احتياطية فورية.
• فتحه بأي أداة تتعامل مع SQLite على أي نظام تشغيل.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

هذا الملف الواحد يحتوي على جداولك وفهارسك ومخطط قاعدة بياناتك وبياناتك كاملةً. والأجمل من ذلك أن قواعد بيانات SQLite المخزّنة على القرص متطابقة بايت ببايت بين Windows وmacOS وLinux وiOS وAndroid. بل إن صيغة الملف مستقرة لدرجة أن مكتبة الكونغرس الأمريكية توصي باستخدامها لحفظ البيانات على المدى الطويل.

أنت تستخدم SQLite بالفعل دون أن تشعر

الجهاز الذي تقرأ منه هذه السطور يحتوي على الأرجح على مئات قواعد بيانات SQLite. فهي تشغّل:

• نظامَي iOS وAndroid وكثيرًا من تطبيقاتهما.
• متصفحات Firefox وChrome وSafari (سجل التصفح، الإشارات المرجعية، ملفات تعريف الارتباط).
• نظام macOS (تطبيق البريد، الصور، شريط Dock).
• معظم تطبيقات سطح المكتب على Linux التي تحتاج تخزينًا محليًا.
• Skype وWhatsApp وSignal — لحفظ سجلات المحادثات.
• كتالوجات Adobe Lightroom، وبيانات Dropbox الوصفية، ومكتبات Steam.

يوصف SQLite بأنه محرك قواعد البيانات الأكثر انتشارًا في العالم، وهذا الوصف دقيق على الأرجح. والسبب بسيط: حين يحتاج أي تطبيق إلى تخزين محلي مُهيكَل، يكون SQLite الخيار الأقل احتكاكًا.

ما لا يصلح له SQLite

ليس قاعدة بيانات بنمط خادم/عميل. لا يستطيع برنامجان على جهازين مختلفين الاتصال بقاعدة بيانات SQLite عبر الشبكة — ببساطة لأنه لا توجد طبقة شبكة أصلًا. إن احتجت ذلك، فالمناسب لك هو PostgreSQL أو MySQL.

كذلك ليس مصمَّمًا للكتابة المتزامنة الكثيفة. يعتمد SQLite على القفل على مستوى الملف (مع بعض التحسينات الذكية في وضع WAL)، فيمكن لعدد كبير من القرّاء العمل بالتوازي، لكن لا يُسمح إلا بكاتب واحد فقط في كل لحظة. بالنسبة لتطبيق فردي أو موقع قليل الزيارات، الأمر لا يُلاحَظ. أما إن كنت تبني منصة SaaS متعددة المستأجرين تستقبل آلاف عمليات الكتابة في الثانية، فهذه ليست الأداة المناسبة.

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

لماذا تختار SQLite؟

المعادلة هنا هي: تنازَل عن قابلية توسّع قد لا تحتاجها أصلًا، مقابل بساطة حقيقية:

• صفر إعداد. لا خدمة تُشغَّل، ولا تعارض في الإصدارات بين بيئة التطوير والإنتاج، ولا رسالة "قاعدة البيانات معطّلة" — لأنه ببساطة لا يوجد خادم ليتعطل.
• سرعة عالية. في معظم أحمال العمل، خصوصًا تلك التي تغلب عليها القراءة، يتفوق SQLite على قواعد البيانات الشبكية، إذ لا توجد رحلة ذهاب وإياب عبر السوكت مع كل استعلام.
• موثوقية صارمة. يخضع SQLite لاختبارات مكثفة بشكل مهووس؛ فحجم كود الاختبارات في المشروع يفوق حجم الكود المصدري بفارق ضخم، وصيغة الملف مستقرة منذ عام 2004.
• ملكية عامة (Public Domain). مجاني لأي استخدام، تجاريًا كان أم غير ذلك. لا يوجد ترخيص أصلًا لتقرأه.
• محمول بين المنصات. ملف واحد يعمل على كل الأنظمة.

في التطبيقات المحلية، والنماذج الأولية، والأجهزة المدمجة، وأدوات سطر الأوامر، ومجموعات الاختبارات، وسكربتات تحليل البيانات، والمواقع الصغيرة والمتوسطة، يكون SQLite في الغالب هو الخيار الصحيح افتراضيًا — لا مجرد خطوة مؤقتة في الطريق إلى قاعدة بيانات "حقيقية".

التالي: الفرق بين SQLite وMySQL

السؤال الذي يطرح نفسه بطبيعة الحال: كيف يقف SQLite أمام خوادم قواعد البيانات التي طالما سمعت عنها؟ سنبدأ بـ MySQL — أين يتفوق كل منهما، وكيف تعرف أيّهما الأنسب لمشروعك الحالي.