SQLite'ı uygulama dosya biçimi olarak kullanmak

• SQLite veritabanı dosyası, uygulama durumunu saklamak veya değiş tokuş etmek için uygun, tek dosya tabanlı bir biçimdir
• Mevcut özel biçimler, dosya yığını (pile-of-files), ZIP tabanlı biçimlere göre daha yapısaldır ve SQL şeması ile açıkça tanımlanabilir
• Transaction, index ve yüksek seviyeli sorgu dili sayesinde veri erişilebilirliği ve kararlılık sağlar; artımlı güncellemeleri ve çoklu süreç erişimini destekler
• Çapraz platform uyumluluğu, genişletilebilirlik, performans ve çeşitli dil arayüzleri ile geliştirme verimliliğini ve bakım kolaylığını artırır
• Açık veri yapısı ve şema merkezli tasarım sayesinde daha iyi uygulama kalitesi ve uzun vadeli veri korunabilirliği sağlar

---

Uygulama dosya biçimi kavramı

• Uygulama dosya biçimi, program durumunu diske kaydetmek veya programlar arasında bilgi alışverişi yapmak için kullanılan dosya yapısıdır
  • Örnekler: DOC, DWG, PDF, XLS, GIT, EPUB, ODT, PPT, ODP
• Dosya biçimi (file format) tek bir nesneyi saklarken (ör. JPEG, GIF, XHTML), uygulama biçimi (application format) birden çok nesneyi ve bunların ilişkilerini birlikte saklar
• Uygulama biçimlerinin çoğu üç türe ayrılır
  • Özel biçim: DOC, DWG, PDF gibi belirli bir uygulamaya özel ikili yapı; harici araçlarla erişilemez
  • Dosya yığını (pile-of-files): Git gibi birden çok dosyadan oluşan yapı; bazı kısımları okunması kolaydır ama taşınabilirlik ve tutarlılık yönetimi zordur
  • ZIP tabanlı biçim (wrapped pile-of-files): EPUB, ODT, ODP gibi dosya yığınlarının ZIP ile sıkıştırılmış hali; tek dosyadır ancak değişiklikte tümünün yeniden yazılması gerekir

SQLite'ı yeni bir uygulama dosya biçimi olarak kullanmak

• SQLite veritabanı, basit bir anahtar/değer şemasıyla bile (CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);) dosya yığını yapısının yerini alabilir
  • Sıkıştırıldığında ZIP arşiviyle boyut farkı ±%1 içinde kalır
  • Tek tek dosyalar düzeyinde değişiklik yapılabildiğinden tüm dosyanın yeniden yazılması gerekmez
• SQLite; çok sayıda tablo, alan, veri tipi, kısıt ve index içerebildiği için karmaşık veri ilişkilerini verimli şekilde ifade eder
• Özel biçim düzeyinde ifade gücü sunarken tanım ve kod miktarı çok daha yalındır ve özel araçlar olmadan erişilebilir

SQLite biçiminin başlıca avantajları

• 1. Geliştirmeyi basitleştirmesi

  • Dosya G/Ç özelliklerini tamamlamak için yalnızca SQLite kütüphanesini veya tek kaynak dosyayı (sqlite3.c) dahil etmek yeterlidir
  • Binlerce satır koddan ve bakım maliyetinden tasarruf sağlar
  • Dünya genelinde milyarlarca SQLite dosyası kullanılmaktadır ve yoğun şekilde test edilmiş bir kararlılık sunar

• 2. Tek dosyalı belge yapısı

  • Tüm veriler tek bir dosyada saklandığı için taşıma, kopyalama ve ekleme kolaydır
  • Dosya başlığındaki Application ID ile belge türü tanımlanabilir

• 3. Yüksek seviyeli sorgu dili

  • SQL ile veri erişim mantığı sadeleşir; geliştirici yalnızca ne istediğini tanımlar
  • Anahtar/değer tabanlı dosyalara göre transaction, index ve şema desteği sayesinde hata olasılığı azalır

• 4. Erişilebilir içerik

  • SQLite dosyaları açıkça belgelenmiş açık bir biçimdir ve komut satırı araçlarıyla doğrudan erişilebilir
  • ABD Kongre Kütüphanesi, bunu uzun vadeli dijital koruma biçimi olarak önermektedir
  • 2004'ten beri süren geriye dönük uyumluluk, uzun vadeli erişimi güvence altına alır

• 5. Çapraz platform uyumluluğu

  • 32/64 bit, endian farkları ve Windows/Unix ailesi arasında tam uyumluluk sağlar
  • Metin için UTF-8 ve UTF-16LE/BE arasında otomatik dönüştürme desteği vardır

• 6. Atomik transaction'lar

  • Sistem hatası veya elektrik kesintisi durumunda bile veri bozulması olmadan eksiksiz yazma garantisi verir
  • Değişiklikler gruplanarak rollback ve doğrulama yapılabilir; Fossil DVCS bu özelliği kullanır

• 7. Artımlı ve sürekli güncelleme

  • Yalnızca değişen kısımlar diske yazıldığı için hız artar ve SSD aşınması azalır
  • Otomatik kaydetme ve oturumlar arası undo/redo yığını koruma mümkündür

• 8. Kolay genişletilebilirlik

  • Yalnızca yeni tablo veya sütun ekleyerek özellik genişletilebilir; mevcut sorgularla uyumluluk korunur
  • Yapısal değişiklikler, özel biçimlere kıyasla çok daha kolaydır

• 9. Performans

  • Dosya yığınından daha hızlı okuma/yazma mümkündür; özellikle 100KB altı BLOB işlemlerinde güçlüdür
  • Sadece index eklemek veya ANALYZE çalıştırmak bile performans iyileştirmesi sağlayabilir
  • Özel biçimlerde aynı sorunu çözmek için kod değişikliği gerekir

• 10. Çoklu süreçte eşzamanlı erişim

  • SQLite eşzamanlı erişimi otomatik olarak koordine eder
  • Birden çok süreç aynı anda okuyabilir, yazma ise sıralı işlenir
  • Biçimin bozulmasını otomatik olarak önler

• 11. Çeşitli programlama dilleri desteği

  • C, C++, C#, Java, Python, Ruby, JavaScript gibi çoğu dil için arayüz sunar
  • Farklı diller ve ekipler ortak bir şema üzerinden birlikte çalışabilir

• 12. Daha iyi uygulama mimarisi

  • SQLite şemasının kendisi, dosya biçiminin eksiksiz dokümantasyonu işlevini görür
  • Özel biçimlerde yüzlerce sayfalık spesifikasyon gerekirken SQL şeması kısa ve açıktır
  • Fred Brooks, Rob Pike ve Linus Torvalds alıntılarıyla veri yapısı merkezli tasarımın önemi vurgulanır

Sonuç

• SQLite her durum için kusursuz olmasa da, çoğu uygulamada özel biçim, dosya yığını ve ZIP biçimlerinden daha iyi bir seçenektir
• Kararlılık, genişletilebilirlik, performans, erişilebilirlik ve uyumluluğu bir araya getiren yüksek seviyeli bir dosya biçimi olarak,
  yeni nesil uygulama tasarımlarında standart dosya biçimi adayı olarak değerlendirilmeyi hak eder

[GN⁺]

Hacker News görüşü

• Geçmişte Mapbox'ta MBTiles formatını oluşturmuştuk
  O sırada iPad için çevrimdışı haritaları araştırıyorduk ve sayısız küçük PNG döşemeyi (256px) USB ya da ağ üzerinden taşımak fazlasıyla zahmetliydi
  Bu yüzden döşemeleri SQLite içinde paketleyip sakladık; böylece taşımak kolaylaştı ve checksum yönetimi de basitleşti
  Döşemeler X, Y, Z (yakınlaştırma seviyesi) ile indeksleniyordu, bu da ilişkisel bir veritabanında çalışmayı kolaylaştırıyordu; ayrıca iPad'de dosya uzantısı ve metadata kullanarak uygulama ikonu bile eklenebiliyorduk
  Dosya formatını sıfırdan tasarlamak göz korkutucuydu ama veritabanlarına aşinaydık, bu yüzden bir CLI aracı yapıp farklı dillerden kolayca kullanılmasını sağladık
  • .zip, .tar, sqlite ve dosya sistemini karşılaştırmalı olarak test ettik; en iyi sıkıştırma oranını ve en düşük ek yükü sqlite verdi
  • MBTiles formatını gerçekten çok seviyorum; bunu yaptığınız için teşekkürler
• SQLite, uygulama formatı olarak gerçekten olağanüstü
  Pek çok araç SQLite verisini okuyabiliyor ve yalnızca CLI ile bile veriyle çalışmak çok pratik
  20 yılı aşkın süredir var ve dünyanın en çok test edilmiş yazılımlarından biri
  Basit ama güçlü ve son derece güvenilir; bu yüzden uzun vadeli veri saklama açısından SQLite'ı dosya formatı olarak kullanmanın en iyi seçeneklerden biri olduğunu düşünüyorum
• Ben de SQLite'ı benzer şekilde kullanıyorum
  Internet-Places-Database projesinde HTML UI kullandım ve bootstrap bileşenleri sayesinde ayrı kurulum olmadan herkes erişebildi
  Tüm veri tek bir SQLite dosyasından okunup döndürülüyor
  Veritabanı büyük olduğu için gezinme yavaş olabiliyor ama verimli bir gezinme yöntemiyle arama alanını daraltmayı düşünüyorum
• Geçmişte bir masaüstü bloglama uygulaması yaparken SQLite kullanmıştım
  Blogun temel yapısını oluşturup bunu dosya olarak aileme veriyordum; onlar da sadece yazı yazıp yayımlıyordu
  İlgili ayrıntıları bu blog yazısında toparlamıştım
• Çoğu uygulama dosya formatı ağaç yapısındadır ama veri düz tablolar biçimindeyse SQLite açık bir tercih
  Ağaç yapısıysa JSON'u blob olarak saklayabilirsiniz ama bu durumda avantajların bir kısmı kaybolur
  Yine de yanında görsel ya da ikili veri varsa SQLite çok daha avantajlıdır — ZIP'ten daha kolay işlenir
  • Veritabanı normalizasyonuna aşina olmasanız bile ağaç yapısını foreign key ilişkileriyle düzleştirmek o kadar zor değil
    SQLite özyinelemeli sorguları da desteklediği için kendine referans veren veriler bile temiz biçimde ifade edilebilir
    JSON blob'u bir TEXT alanına koymak kolaydır ama bu, SQL'in migration ve indexing gibi avantajlarını kaybettirir
  • İlişkisel saklamanın özü, veriye tek bir belge olarak bakmamak ve onun farklı açılardan çıkarılabilmesini sağlamaktır
    Verinin çoğu görünüşte hiyerarşiktir ama bunu farklı kesitlerden bölerseniz ilişkisel bir yapıya dönüşür
    Yine de programlama dillerinde ilişkisel tiplerin iyi ifade edilememesi üzücü
  • JSON verisine not eklemek için bir arayüze ihtiyacım vardı; Codex'ten SQLite tabanlı bir web sunucusu yapmasını istedim ve kısa sürede tamamladı
    SQLite, JSON benzeri nesneler üzerinde sorguları da destekliyor
    Ama CLI o kadar minimal ki, daha iyi bir araç kullanmalıydım diye düşündüm
  • SQLite'ta birden fazla tablo oluşturup referans ilişkileri kurabilirsiniz
    Hatta özyinelemeli referanslar bile mümkün
• Bununla ilgili daha önce bir tartışma vardı — önceki başlık
• Benzer yaklaşımı kendi işimde de uyguladım
  DuckDB kullanarak hiyerarşik bir modelin çıktı dosyalarını SQL ile sorgulanabilir tek bir dosyada topladım; böylece depolama ve analiz hattı sadeleşti
  Uzun vadeli veri korumasının önemli olduğu durumlarda SQLite özellikle ideal görünüyor
  • Sanırım geliştiriciler de aynı fikirle Fossil SCM'yi oluşturdu
• Ekibimiz UAT ortamından üretim ortamına yapılandırma taşırken SQLite kullanıyor
  Yapılandırmalar zaten Postgres tablolarında saklandığı için, bazı ayarları SQLite dosyasına aktarıp kolayca dağıtabiliyoruz
  İkili format olduğu için yanlışlıkla değiştirilme riski de azalıyor
  Tersine, üretim verisini test amaçlı dışa aktarırken de bunu SQLite dosyası olarak kolayca kodlayabiliyoruz
• Küçükken WinRAR ile oyun ya da program dosyalarını açıp gizli kaynakları aradığımı hatırlıyorum
• Tamamen ikna oldum
  İnsanların nasıl bu kadar iyi fikir ya da ürün pazarlayabildiğini hep merak etmişimdir