SQLite ATTACH DATABASE: Birden Fazla Dosyada Sorgu

Tek Bağlantı, Birden Fazla Dosya

SQLite'ta bir bağlantı tek bir dosyaya mahkum değildir. ATTACH DATABASE ile, halihazırda açtığınız veritabanının yanına başka .db dosyaları da bağlayabilir ve hepsini sanki tek bir veritabanının içindeki şemalarmış gibi sorgulayabilirsiniz. SQLite'ın "tek sunucuda birden fazla veritabanı" mantığına en yakın çözümü budur.

Temel kullanım şöyle:

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, 'Rosa', 49.99);

SELECT * FROM archive.old_orders;

archive.db dosyası, ana veritabanında olduğu gibi, eğer yoksa otomatik olarak oluşturulur. Bu oturum boyunca archive. ön ekiyle gelen her şey bu ikinci dosyada, main. ön ekiyle gelen (ya da hiç ön ek almayan) her şey ise orijinal veritabanında yaşar.

Her bağlantınızda zaten örtük olarak iki şema bulunur: main (ilk açtığınız dosya) ve temp (geçici tablolar için kullanılan bir karalama alanı). ATTACH ile bunlara yenilerini eklersiniz.

Söz dizimi ve takma adın işlevi

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

Bu takma ad (alias), tablolara erişirken kullanacağın şema adıdır. Yalnızca aktif bağlantıya özgüdür — aynı dosyayı bağlayan başka bir bağlantı farklı bir alias seçebilir. Bunu çok yazacağın için kısa ve açıklayıcı bir isim seç (archive, analytics, cache gibi).

Bilmeniz gereken birkaç ufak nokta var:

• Yol mutlak değilse, sürecin çalışma dizinine göre değerlendirilir.
• ':memory:' ifadesi, o alias altına yepyeni bir bellek içi (in-memory) veritabanı bağlar.
• Alias, main veya temp ile çakışamaz ve aynı bağlantıda birden fazla kez kullanılamaz.

Farklı Veritabanları Arasında Join Yapmak

İnsanların ATTACH kullanmasının başlıca sebebi tam da budur. İki dosya aynı bağlantıya bağlandığında, tek bir sorguda bu dosyaların tablolarını join'leyebilirsiniz:

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;

Sorgu planlayıcı, eklenen şemayı main içindeki tablolarla aynı şekilde değerlendirir. Eklenen tablolardaki indeksler kullanılır, EXPLAIN QUERY PLAN veritabanları arasında sorunsuz çalışır. Ortada ağ üzerinden gidip gelen bir istek de yok — iki dosya da aynı süreçte açık duruyor.

Bu yöntem; sıcak veriyi soğuk arşivden ayırmak, kiracı başına ayrı dosyalar tutmak ya da salt okunur bir referans veritabanından sabit verileri çekmek için gerçekten işe yarıyor.

Salt okunur ve bellek içi veritabanı bağlama

İkinci veritabanını yalnızca okumak istiyor, üzerine yazmayı düşünmüyorsanız — örneğin uygulamayla birlikte dağıttığınız sabit bir referans veri kümesi — onu URI kullanarak salt okunur şekilde bağlayabilirsiniz:

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

URI biçiminin çalışması için SQLite kütüphanesinde SQLITE_OPEN_URI özelliğinin etkin olması gerekir (CLI'da ve çoğu dil bağlamasında zaten açıktır). Bu sayede ref.* üzerinde yapılacak herhangi bir INSERT, UPDATE ya da DELETE işlemi, dosyaya hiç dokunmadan hata fırlatır.

Bellek içi (in-memory) bağlamalar da geçici veri hazırlamak için bir o kadar kullanışlıdır:

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 veritabanı, bağlantı kapandığında uçup gider. Aslında temp gibi davranır ama ömrünü sen kontrol edersiniz.

Transactions Tüm Bağlı Veritabanlarını Kapsar

Tek bir BEGIN/COMMIT bloğu, hem main üzerindeki hem de eklenmiş (attach edilmiş) tüm şemalardaki yazma işlemlerini birlikte ele alır. Yani ya hepsi birden işlenir ya da hepsi geri alınır — atomiklik dosyalar arasında bile korunur:

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;

Canlı bir tablodaki satırları arşiv dosyasına taşımak, tam da bu garantiye ihtiyaç duyacağınız türden bir işlemdir. Dosyalar arası atomiklik olmadan, işlemin ortasında yaşanacak bir çökme size ya yinelenmiş satırlar bırakır ya da daha kötüsü, satırlarınızın bir kısmını kaybetmenize yol açar.

Şuna da dikkat: bir transaction içinde birden fazla bağlı veritabanına yazılıyorsa, SQLite geçici bir journal dosyası gerektiren daha temkinli bir commit protokolüne geçer. Tek dosyalı commit'lere göre yavaştır ama yine de güvenlidir.

Veritabanı bağlantısını kaldırma (DETACH)

Bağladığınız veritabanıyla işiniz bittiğinde onu çıkarın:

DETACH DATABASE archive;

Dosyanın kendisi diskte olduğu gibi kalır — DETACH yalnızca o bağlantıdaki handle'ı kapatır. Aklınızda tutmanız gereken iki kısıt var:

• main ve temp veritabanlarını detach edemezsiniz.
• Aktif bir transaction içinde olan ya da üzerinde açık statement bulunan bir veritabanını detach edemezsiniz.

Detach etmeyi unutursanız da dünyanın sonu değil: bağlantı kapandığında her şey temizlenir.

Sınırlar ve sık karşılaşılan hatalar

Bilmeniz gereken birkaç pratik sınır var:

• Bağlantı başına varsayılan üst sınır 10 attached veritabanıdır (main ve temp buna dahil değil). Derleme zamanı maksimumu ise 125. Bu sınırı aştığınızda too many attached databases - max 10 hatasını görürsünüz.
• Her attach edilen dosya bir page cache kullanır. Bir düzine büyük veritabanını attach etmek bedelsiz değildir — RAM tüketimi artar.
• ATTACH komutu transaction içinde çalıştırılamaz. Onu BEGIN'den önce ya da COMMIT'ten sonra çalıştırın.

Karşılaşmanız muhtemel birkaç hata:

-- Dosya mevcut değil ve dizin yazılabilir değil:
Error: unable to open database: 'missing/path.db'

-- Salt okunur bir eke yazmaya çalıştınız:
Error: attempt to write a readonly database

-- Aynı takma adı iki kez kullandınız:
Error: database archive is already in use

Çoğu hata, okur okumaz "haa, tabii ya" dedirten cinsten. Ama bir tanesi insanı yanıltıyor: "already in use" hatası. ATTACH mevcut bir alias'ın üzerine yazmıyor; önce DETACH etmeniz gerekiyor.

Gerçekçi Bir Senaryo: Sıcak/Soğuk Veri Ayrımı

Şimdi öğrendiklerimizi birleştirelim — bir yıldan eski siparişleri ana veritabanından arşive taşıyan küçük bir iş akışı:

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;

Eski satırlar archive.orders tablosuna taşınır, yeni olanlar ise main içinde kalır. Geçmişe ihtiyaç duyan raporlar iki veritabanı arasında join atabilir; günlük sorgular ise tablo daha küçük kaldığı için main.orders üzerinde hızlı çalışmaya devam eder. Tek bağlantı, iki dosya, tek transaction.

Sırada: Prepared Statements

ATTACH, tek bir bağlantıya daha fazla veriye erişim kazandırmakla ilgilidir. Bundan sonraki konular ise uygulamaların SQLite ile güvenli ve verimli şekilde nasıl konuştuğunu ele alacak — parametre bağlama ve SQL injection'a kapalı sorguların temeli olan prepared statements ile başlıyoruz.