ATTACH DATABASE في SQLite: استعلام عبر عدة ملفات

اتصال واحد، ملفات متعددة

اتصال SQLite ليس مقيّداً بملف واحد فقط. عبر الأمر ATTACH DATABASE يمكنك فتح ملفات .db إضافية إلى جانب الملف الذي بدأت به، ثم الاستعلام عنها جميعاً وكأنها مخططات (schemas) داخل قاعدة بيانات واحدة. هذه أقرب ميزة يقدّمها SQLite لمفهوم "عدة قواعد بيانات على خادم واحد".

الصيغة الأساسية:

ATTACH DATABASE 'archive.db' AS archive;

CREATE TABLE archive.old_orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    total REAL
);

INSERT INTO archive.old_orders VALUES (1, 'روزا', 49.99);

SELECT * FROM archive.old_orders;

يُنشَأ ملف archive.db تلقائيًا إن لم يكن موجودًا، تمامًا كما يحصل مع قاعدة البيانات الرئيسية. ومن هذه اللحظة وحتى نهاية الجلسة، كل ما يبدأ بالبادئة archive. يُخزَّن في هذا الملف الثاني، بينما يبقى كل ما يبدأ بـ main. (أو بدون بادئة أصلًا) في الملف الأصلي.

أي اتصال بـ SQLite يحمل بشكل ضمني مخططَين: main (وهو الملف الذي فتحته أول مرة) وtemp (مساحة مؤقتة للجداول العابرة). وعملية الربط (ATTACH) تضيف مخططات أخرى فوق هذين.

صيغة ATTACH DATABASE وما الذي يفعله الاسم المستعار

ATTACH DATABASE 'path/to/file.db' AS alias_name;

الاسم المستعار هنا هو اسم المخطط (schema) الذي ستستخدمه لتأهيل أسماء الجداول. وهو محصور في نطاق الاتصال الحالي فقط، أي أن اتصالاً آخر يربط نفس الملف يمكنه اختيار اسم مستعار مختلف. اختر اسماً قصيراً ومعبّراً مثل archive أو analytics أو cache، لأنك ستكتبه كثيراً.

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

• المسار يكون نسبياً إلى مجلد العمل الخاص بالعملية، ما لم يكن مساراً مطلقاً.
• النص ':memory:' يربط قاعدة بيانات جديدة في الذاكرة (in-memory database) تحت ذلك الاسم المستعار.
• لا يمكن أن يتعارض الاسم المستعار مع main أو temp، ولا يمكن تكراره بين عمليات الربط.

الاستعلام عبر قواعد بيانات SQLite متعددة

هذه هي الميزة التي يلجأ معظم الناس إلى ATTACH من أجلها. بمجرد أن يصبح الملفان ضمن نفس الاتصال، يمكنك تنفيذ join بين جداولهما في استعلام واحد:

ATTACH DATABASE ':memory:' AS archive;

CREATE TABLE main.customers (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE archive.orders (id INTEGER, customer_id INTEGER, total REAL);

INSERT INTO main.customers VALUES (1, 'Rosa'), (2, 'Boris');
INSERT INTO archive.orders VALUES (101, 1, 49.99), (102, 2, 12.50);

SELECT c.name, o.total
FROM main.customers AS c
JOIN archive.orders AS o ON o.customer_id = c.id;

مُخطِّط الاستعلامات يتعامل مع كلا الـ schema بنفس الطريقة التي يتعامل بها مع الجداول في main. الفهارس على الجداول المرفقة تُستخدم بشكل طبيعي، وEXPLAIN QUERY PLAN يعمل عبرها دون مشاكل. لا توجد أي رحلات عبر الشبكة — كلا الملفين مفتوحان داخل نفس العملية.

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

ربط قاعدة بيانات للقراءة فقط أو في الذاكرة

إذا كانت قاعدة البيانات الثانية مجرد بيانات تريد قراءتها دون تعديلها — مثل مجموعة بيانات مرجعية تأتي مع التطبيق — فاربطها بوضع القراءة فقط عبر URI:

ATTACH DATABASE 'file:reference.db?mode=ro' AS ref;

صيغة URI تتطلب أن تكون مكتبة SQLite مفعَّلة فيها SQLITE_OPEN_URI (وهي مفعَّلة في واجهة سطر الأوامر ومعظم رِبط اللغات). بعد ذلك، أي عملية INSERT أو UPDATE أو DELETE على ref.* ستُطلق خطأً قبل أن تمس الملف أصلاً.

وكذلك يُعدّ ربط قواعد البيانات في الذاكرة (in-memory) مفيداً جداً لتجهيز البيانات مؤقتاً:

ATTACH DATABASE ':memory:' AS scratch;

CREATE TABLE scratch.tmp_results AS
SELECT customer_id, SUM(total) AS spend
FROM main.orders
GROUP BY customer_id;

SELECT * FROM scratch.tmp_results ORDER BY spend DESC LIMIT 5;

scratch تختفي بمجرد إغلاق الاتصال. تشبه temp لكن مع إعطائك التحكم الكامل بعمرها.

المعاملات تشمل كل قواعد البيانات المرتبطة

أي BEGIN/COMMIT واحد يغطي عمليات الكتابة على main وعلى كل المخططات المرتبطة. فإمّا أن يُحفظ كل شيء أو يُتراجع عنه بالكامل، وبهذا تبقى الذرّية (atomicity) مصونة عبر الملفات المختلفة:

ATTACH DATABASE ':memory:' AS archive;

CREATE TABLE main.orders (id INTEGER PRIMARY KEY, total REAL);
CREATE TABLE archive.orders (id INTEGER PRIMARY KEY, total REAL);

BEGIN;
    INSERT INTO archive.orders SELECT * FROM main.orders WHERE id < 100;
    DELETE FROM main.orders WHERE id < 100;
COMMIT;

نقل الصفوف من جدول حيّ إلى ملف أرشيف هو بالضبط نوع العمليات التي تحتاج فيها إلى هذا الضمان. فبدون الذرّية (atomicity) عبر الملفات، أي تعطّل في المنتصف سيتركك أمام صفوف مكرّرة، أو الأسوأ من ذلك: صفوف مفقودة.

لكن انتبه لنقطة مهمة: عند الكتابة في أكثر من قاعدة بيانات مرفقة ضمن المعاملة الواحدة، يلجأ SQLite إلى بروتوكول إيداع (commit) أكثر تحفّظاً يتطلّب ملف journal مؤقّتاً. هذا الأسلوب أبطأ من الإيداع على ملف واحد، لكنه يبقى آمناً.

فصل قاعدة البيانات باستخدام DETACH DATABASE

عند انتهائك من قاعدة البيانات المرفقة، افصلها:

DETACH DATABASE archive;

الملف يبقى على القرص كما هو دون أي تغيير، فالأمر DETACH يقتصر على إغلاق الـ handle داخل الاتصال الحالي. هناك قيدان ينبغي تذكرهما:

• لا يمكنك فصل قاعدة البيانات main أو temp.
• لا يمكنك فصل قاعدة بيانات مرتبطة حاليًا بعملية (transaction) جارية أو لها استعلامات مفتوحة عليها.

وإن نسيت تنفيذ DETACH، فالأمر ليس كارثة؛ مجرد إغلاق الاتصال يكفي لتنظيف كل شيء تلقائيًا.

الحدود والأخطاء الشائعة

إليك بعض الحدود العملية التي يُستحسن معرفتها:

• الحد الافتراضي هو 10 قواعد بيانات مرفقة لكل اتصال (إضافة إلى main وtemp). أما الحد الأقصى وقت التصريف فهو 125. إن تجاوزت الحد ستظهر لك الرسالة too many attached databases - max 10.
• كل ملف مرفق يستهلك ذاكرة تخزين مؤقت للصفحات (page cache). إرفاق عشرات قواعد البيانات الضخمة ليس مجانيًا، فاستهلاك الذاكرة سيرتفع.
• لا يمكن تنفيذ ATTACH نفسه داخل transaction. شغّله قبل BEGIN أو بعد COMMIT.

وإليك بعض الأخطاء التي يُرجَّح أن تصادفها:

-- الملف غير موجود والمجلد غير قابل للكتابة:
Error: unable to open database: 'missing/path.db'

-- حاولت الكتابة إلى مرفق للقراءة فقط:
Error: attempt to write a readonly database

-- استخدمت نفس الاسم المستعار مرتين:
Error: database archive is already in use

معظم هذه الأخطاء واضحة بمجرد قراءتها. لكن خطأ "already in use" هو الذي يُربك الناس عادةً — فأمر ATTACH لا يستبدل اسماً مستعاراً موجوداً مسبقاً، بل عليك تنفيذ DETACH أولاً.

نمط عملي: الفصل بين البيانات الساخنة والباردة

لنجمع كل ما سبق في سيناريو واقعي — سير عمل أرشفة بسيط ينقل الطلبات الأقدم من سنة من قاعدة البيانات الرئيسية إلى أخرى مخصصة للأرشيف:

ATTACH DATABASE ':memory:' AS archive;

CREATE TABLE main.orders (
    id INTEGER PRIMARY KEY,
    placed_at TEXT,
    total REAL
);
CREATE TABLE archive.orders AS SELECT * FROM main.orders WHERE 0;

INSERT INTO main.orders VALUES
    (1, '2022-06-01', 19.99),
    (2, '2024-11-15', 49.50),
    (3, '2025-08-22', 12.00);

BEGIN;
    INSERT INTO archive.orders
        SELECT * FROM main.orders WHERE placed_at < date('now', '-1 year');
    DELETE FROM main.orders WHERE placed_at < date('now', '-1 year');
COMMIT;

SELECT 'main' AS db, COUNT(*) FROM main.orders
UNION ALL
SELECT 'archive', COUNT(*) FROM archive.orders;

تنتقل الصفوف القديمة إلى archive.orders، بينما تبقى الصفوف الحديثة في main. التقارير التي تحتاج إلى السجل التاريخي يمكنها عمل join بين القاعدتين، أما الاستعلامات اليومية على main.orders فتظل سريعة لأن الجدول أصبح أصغر. اتصال واحد، ملفان، ومعاملة واحدة.

الخطوة التالية: Prepared Statements

الهدف من ATTACH هو منح اتصال واحد صلاحية الوصول إلى بيانات أكثر. أما المواضيع القادمة فتدور حول الطريقة التي تتواصل بها التطبيقات مع SQLite بأمان وكفاءة، وسنبدأها بـ prepared statements، فهي الأساس الذي يقوم عليه ربط المعاملات (parameter binding) وكتابة استعلامات محصّنة ضد هجمات الحقن.