Geri Dön
SQLite için bir öneri: dört kötü varsayılanı düzeltecek tek pragma
SiTech AI Team2 წთ. საკითხავი

SQLite için bir öneri: dört kötü varsayılanı düzeltecek tek pragma

Bir blog yazısı, SQLite'ın varsayılanlarının — kapalı yabancı anahtarlar, katı tiplemenin yokluğu, anında SQLITE_BUSY hataları ve WAL'sız çalışma — eski yazılımları bozmadan modern davranışa geçilen Rust tarzı bir edition pragmasıyla değiştirilmesini öneriyor.

SQLite yerel veri depolama için sektör standardı; geleneksel bir veritabanı sunucusundan farklı olarak ayrı bir süreç değil, kütüphane biçiminde bir RDBMS olduğu için uygulamalar kendi kendine yeterli kalıyor. Ancak 15 Temmuz'da yayımlanan bir yazıda geliştirici Mort, varsayılanların yanlış olduğunu ve motorun eski yazılımları bozmadan ilerleyebileceği bir yola ihtiyaç duyduğunu savunuyor.

Yazarın değiştirmek istediği dört varsayılan

İlki, PRAGMA foreign_keys = ON çalıştırılmadıkça SQLite'ın yok saydığı yabancı anahtar kısıtları. Yazar, bunları varsayılan olarak uygulamayan bildiği tek RDBMS'in SQLite olduğunu söylüyor ve SQLite'ın ROWID değerlerini yeniden kullanma eğiliminin sonuçları ağırlaştırdığını belirtiyor: bağlantısız bir referans sessizce yanlış satırı gösterebiliyor. Örneğinde, silinen bir kullanıcının bıraktığı gönderiyi aynı ID'yi alan yeni bir hesap devralıyor.

İkincisi tipleme. INTEGER olarak tanımlanan bir sütun INTEGER affinity kullanır; yani sayıya benzeyen metin sayı olarak, geri kalan her şey olduğu gibi saklanır. Bu yüzden bir süre sütunu “Way too long, I mean come on” metnini tutabiliyor. STRICT tablolar bunu düzeltiyor — INTEGER sütuna TEXT eklemek hata veriyor — ancak tüm tabloları katı yapan bir pragma yok, dolayısıyla anahtar sözcüğü elle eklemek gerekiyor.

Üçüncüsü eşzamanlılık: SQLite çok sayıda okuyucuya ama tek bir yazıcıya izin veriyor ve varsayılan olarak yazma kilidini almaya çalışan ikinci süreç anında SQLITE_BUSY hatası alıyor. Yazar, kilidi bir zaman aşımına kadar beklemeyi tercih ediyor (PRAGMA busy_timeout = 5000); bu ayarı ancak üretimde gerçek çökmeler yaşadıktan sonra eklediğini söylüyor.

Performans ve edition önerisi

Dördüncüsü performans. Önden yazma günlüğü varsayılan olarak kapalı; PRAGMA journal_mode = WAL etkinleştirmek çoğu durumda yazmayı büyük ölçüde hızlandırıyor ve PRAGMA synchronous = NORMAL ile birlikte bozulma riski olmadan disk senkronizasyonu sayısını ciddi biçimde azaltıyor. Yazı, ayrıntılar için Sylvain Kerkour'un SQLite'ı sunucular için optimize etme makalesine işaret ediyor.

Tüm bunları geriye dönük uyumluluğu bozmadan düzeltmek için — varsayılanları korumanın olağan gerekçesi — yazar tek bir süper pragma öneriyor: PRAGMA edition = 2026; foreign_keys = ON, busy_timeout = 5000, journal_mode = WAL ve synchronous = NORMAL için bir takma ad, ayrıca varsayılan olarak STRICT tablolar.

Fikir doğrudan Rust editions'tan alınmış. Yazara göre yıla dayalı bir edition, JavaScript'teki “use strict” benzeri bir yaklaşımdan daha iyi, çünkü makul varsayılanlar zamanla değişiyor: gelecekte WAL2 gibi bir günlük biçimi ana dala girerse, PRAGMA edition = 2034 onu ayarlayabilir. Bir okuyucu yorumu, SQL 99'un CREATE DOMAIN ile tür takma adlarını zaten tanımladığını hatırlatıyor.

SSiTech

SiTech — AI destekli web geliştirme

Hızlı ve modern web siteleri kuruyor, AI'yı gerçek iş akışlarına taşıyoruz. Projeniz veya sorunuz mu var? Yardımcı olmaktan mutluluk duyarız.