موبائل ڈیولپمنٹ میں SQLite: یہ کیا ہے اور کیسے کام کرتا ہے

SQLite کیا ہے؟

SQLite C زبان کی ایک لائبریری ہے جو بغیر سرشار سرور کے رلیشنل DBMS کو نافذ کرتی ہے۔ یہ براہ راست ایپلیکیشن میں ایمبیڈ ہوتی ہے، ڈیوائس کے فائل سسٹم پر ایک عام فائل میں ڈیٹا پڑھتی اور لکھتی ہے۔ لائبریری کا سائز تقریباً 600 KB ہے، جو SQLite کو سب سے ہلکا مکمل خصوصیات والا SQL ڈیٹابیس بناتا ہے۔

SQLite SQL:1999 معیار کے بیشتر حصے کو سپورٹ کرتا ہے، جس میں JOIN، ذیلی سوالات، ٹرگر، ویوز، انڈیکس اور ونڈو فنکشنز شامل ہیں۔ حدود ALTER TABLE (محدود سپورٹ) اور مکمل RIGHT/FULL OUTER JOIN سے متعلق ہیں۔ پھر بھی، موبائل ایپلیکیشنز کے لیے، SQLite کی فعالیت مقامی اسٹوریج کے 99% معاملات میں کافی ہے۔

Stack Overflow ڈیویلپر سروے (2025) کے مطابق، SQLite ایمبیڈڈ حل کے لیے سب سے مقبول ڈیٹابیس ہے اور MySQL اور PostgreSQL کے بعد تمام DBMS میں مقبولیت میں تیسرے نمبر پر ہے۔ موبائل ڈیولپمنٹ میں، SQLite ہر ایپلیکیشن میں استعمال ہوتا ہے — براہ راست یا ریپر کے ذریعے۔

SQLite کی اہم خصوصیات

صفر کنفیگریشن — SQLite کو انسٹالیشن، اجازت سیٹ اپ، صارف بنانے یا سروس شروع کرنے کی ضرورت نہیں ہے۔ لائبریری پروجیکٹ سے منسلک ہوتی ہے اور ڈیٹابیس ایک فنکشن کال کر کے بنایا جاتا ہے۔ یہ کلائنٹ-سرور DBMS کے مقابلے میں ڈپلائمنٹ کو یکسر آسان بناتا ہے، جس میں سرور انسٹالیشن، پورٹ کنفیگریشن اور صارف سیٹ اپ کی ضرورت ہوتی ہے۔

SQLite ڈیٹابیس فائل ایک عام کراس پلیٹ فارم فائل ہے جسے کاپی، تجزیہ، نیٹ ورک پر بھیجا یا بیک اپ سے بحال کیا جا سکتا ہے۔ فائل فارمیٹ API سطح پر مستحکم ہے: 2004 میں بنائی گئی SQLite 3 فائلیں لائبریری کے موجودہ ورژن سے کھلتی ہیں، جو طویل مدتی ڈیٹا مطابقت کو یقینی بناتی ہیں۔

SQLite کیسے کام کرتا ہے: فن تعمیر اور اسٹوریج

SQLite کا فن تعمیر آٹھ ورچوئل مشینوں پر مشتمل ہے: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface اور Utilities۔ ایک SQL سوال Tokenizer (ٹوکن میں تقسیم)، Parser (AST تعمیر)، Code Generator (بائٹ کوڈ میں تبدیلی) سے گزرتا ہے اور ورچوئل مشین پر عملدرآمد ہوتا ہے، جو B-Tree اور Pager کے ذریعے ڈیٹا کے صفحات پڑھتی ہے۔

SQLite ٹیبلز اور انڈیکس کو ذخیرہ کرنے کے لیے B-Tree استعمال کرتا ہے۔ ہر ٹیبل ایک علیحدہ B-Tree کے طور پر محفوظ ہوتی ہے، جہاں لیف نوڈس میں ڈیٹا کی قطاریں ہوتی ہیں۔ انڈیکس بھی B-Tree کے طور پر محفوظ ہوتے ہیں لیکن لیوز میں کلیدوں کے ساتھ۔ Pager فائل سے میموری میں صفحات (ڈیفالٹ 4096 بائٹ) لوڈ کرنے کا انتظام کرتا ہے، جو جرنل یا WAL کے ذریعے ACID ٹرانزیکشنز فراہم کرتا ہے۔

جرنلنگ موڈز

WAL (Write-Ahead Logging) موبائل ایپلیکیشنز کے لیے تجویز کردہ موڈ ہے۔ تبدیلیاں پہلے ایک علیحدہ WAL فائل میں لکھی جاتی ہیں اور پھر وقتاً فوقتاً مرکزی ڈیٹابیس میں منتقل کی جاتی ہیں۔ WAL ڈیٹابیس سے بیک وقت پڑھنے (پرانا ڈیٹا) اور لکھنے (WAL کے ذریعے) کی اجازت دیتا ہے، جو ملٹی تھریڈڈ ایپلیکیشنز کی کارکردگی کو بہتر بناتا ہے۔ معیاری جرنل (رول بیک جرنل) لکھتے وقت پڑھنے کو روکتا ہے۔

موڈز کے درمیان سوئچنگ ایک SQL سوال سے کی جاتی ہے: PRAGMA journal_mode=WAL. بیک گراؤنڈ سنکرونائزیشن اور بیک وقت ڈیٹا پڑھنے والے UI تھریڈ والی موبائل ایپلیکیشنز کے لیے، WAL بہتر کارکردگی اور انٹرفیس کی عدم موجودگی فراہم کرتا ہے۔

موبائل ڈیولپمنٹ میں SQLite بمقابلہ دیگر ڈیٹابیس

SQLite مقامی ڈیٹا اسٹوریج کا واحد آپشن نہیں ہے، لیکن سب سے زیادہ ورسٹائل ہے۔ Realm میموری میں آبجیکٹ تک براہ راست رسائی کی تیز رفتار فراہم کرتا ہے لیکن اپنا NoSQL فارمیٹ استعمال کرتا ہے اور اس کا لائبریری سائز بڑا ہے۔ iOS پر Core Data SQLite کے اوپر ایک ORM پرت ہے جو آبجیکٹ گراف مینجمنٹ اور آپریشن انڈو شامل کرتی ہے۔

زیادہ تر ایپلیکیشنز کے لیے، SQLite پیش قیاسی کارکردگی، صفر وینڈر لاک ان اور وقت آزمائے استحکام کی وجہ سے بہترین انتخاب ہے۔ Realm اور Core Data پیچیدہ آبجیکٹ گراف، ری ایکٹیو سوالات یا کراس ڈیوائس سنکرونائزیشن کی ضروریات والے پروجیکٹس میں جائز ہیں۔

SQLite, Realm اور Core Data کے درمیان انتخاب پلیٹ فارم، آبجیکٹ ماڈل کی ضروریات اور سنکرونائزیشن کی حکمت عملی پر منحصر ہے۔ کراس پلیٹ فارم پروجیکٹس (KMP, Flutter) کے لیے، SQLite واحد عالمگیر انتخاب ہے جو ڈیٹا ماڈل میں تبدیلی کے بغیر تمام ہدف پلیٹ فارمز پر کام کرتا ہے۔

Android پر SQLite: Room اور SQLiteOpenHelper

Room Android Jetpack کی ایک لائبریری ہے جو SQLite کے اوپر ORM پرت فراہم کرتی ہے۔ Room اینوٹیٹڈ DAO انٹرفیس سے خود بخود SQL سوالات پیدا کرتا ہے، کمپائل ٹائم پر سوالات کی درستگی کی تصدیق کرتا ہے اور اسکیما تبدیل ہونے پر ڈیٹابیس مائیگریشن کو سپورٹ کرتا ہے۔ Android پر SQLite کے ساتھ کام کرنے کا تجویز کردہ طریقہ Room ہے۔

SQLiteOpenHelper ORM کے بغیر براہ راست SQLite مینجمنٹ کے لیے نچلی سطح کا API ہے۔ کلاس ڈیٹابیس بنانے، کھولنے اور اپ گریڈ کرنے کا انتظام کرتی ہے۔ SQLiteOpenHelper سادہ SQL سوالات والے پروجیکٹس یا جب Room کے تجرید کے بغیر SQL منطق پر مکمل کنٹرول کی ضرورت ہو تو موزوں ہے۔

Room کے لیے اینٹیٹی اور DAO کی مثال

Room میں ایک اینٹیٹی کو @Entity سے اور DAO کو @Dao سے اینوٹیٹ کیا جاتا ہے۔ Room اینوٹیٹڈ طریقوں کو SQL سوالات میں ترجمہ کرتا ہے: @Insert INSERT بناتا ہے، @Query مخصوص SQL کے ساتھ SELECT بناتا ہے۔ مائیگریشن پرانے اور نئے اسکیما ورژن کی وضاحت کرتے ہوئے Migration کلاسز کے ذریعے شامل کی جاتی ہیں۔ Room کمپائل ٹائم پر SQL کی تصدیق کرتا ہے، پروڈکشن میں نحوی غلطیوں کو ختم کرتا ہے۔

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

Room خود بخود UserDao_Impl کا نفاذ پیدا کرتا ہے، جس میں داخلی RoomDatabase کے ذریعے رن ٹائم SQLite سوالات شامل ہیں۔ کوروٹین (suspend) کی بدولت، DAO طریقے UI کو روکے بغیر بیک گراؤنڈ تھریڈ پر غیر مطابقت پذیر طور پر عملدرآمد ہوتے ہیں۔ @Query میں Flow کی واپسی کی قسمیں ٹیبل تبدیل ہونے پر خود بخود نتیجہ اپ ڈیٹ کرتی ہیں۔

iOS پر SQLite: FMDB اور GRDB

FMDB SQLite C API پر ایک Objective-C ریپر ہے، تاریخی طور پر iOS کے لیے پہلی مقبول لائبریری۔ یہ سوالات پر عملدرآمد اور نتائج حاصل کرنے کے لیے FMDatabase اور FMResultSet آبجیکٹ فراہم کرتی ہے۔ FMDB سادہ اور کم سے کم ہے، لیکن Swift مخصوص تعمیرات — آپشنلز, Codable, async/await کو سپورٹ نہیں کرتی۔

GRDB SQLite کے ساتھ کام کرنے کے لیے ایک جدید Swift لائبریری ہے۔ یہ ٹائپ سیف API, Codable سپورٹ, Combine Publishers, async/await, مائیگریشنز اور ریئل ٹائم تبدیلی مشاہدہ فراہم کرتی ہے۔ GRDB Swift Concurrency کے ساتھ مکمل انضمام اور بہتر کوڈ پڑھنے کی اہلیت کی وجہ سے نئے Swift پروجیکٹس کے لیے ترجیح دی جاتی ہے۔

Swift میں GRDB کی مثال

GRDB FetchableRecord اور TableRecord پروٹوکولز کی تعمیل کرنے والی Record کلاسز کے ذریعے ٹیبلز کی وضاحت کرتی ہے۔ سوالات خام SQL کے بجائے ٹائپ سیف سنٹیکس کے ساتھ Swift میں لکھے جاتے ہیں۔ GRDB اسکیما ورژننگ اور ایپ ورژنز کے درمیان مائیگریشن کے لیے DatabaseMigrator کو بھی سپورٹ کرتی ہے۔

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

DatabasePool بیک وقت پڑھنے کے لیے SQLite کے WAL موڈ کا استعمال کرتا ہے۔ متعدد قارئین بیک وقت ڈیٹابیس تک رسائی حاصل کر سکتے ہیں جبکہ ایک واحد مصنف WAL کے ذریعے ڈیٹا اپ ڈیٹ کرتا ہے۔ GRDB خود بخود کنکشنز اور ٹرانزیکشنز کا انتظام کرتا ہے، دستی سنکرونائزیشن کے بغیر کسی بھی تھریڈ سے تھریڈ سیف ڈیٹابیس تک رسائی فراہم کرتا ہے۔

SQLite کارکردگی کی اصلاح

انڈیکس SQLite سوالات کو تیز کرنے کا سب سے مؤثر طریقہ ہے۔ WHERE, JOIN اور ORDER BY میں استعمال ہونے والے کالموں پر انڈیکس بنایا جاتا ہے۔ 100000 ریکارڈ والی ٹیبل کے لیے، انڈیکس شدہ کالم پر تلاش سیکنڈوں کے بجائے ملی سیکنڈز میں ہوتی ہے۔ تاہم، انڈیکس INSERT اور UPDATE کو سست کرتے ہیں، اس لیے ان کی تعداد لکھنے کی فریکوئنسی کے ساتھ متوازن ہونی چاہیے۔

ایک ہی ٹرانزیکشن کے اندر بیچ انسرٹ بڑی مقدار میں ڈیٹا لوڈنگ کو یکسر تیز کرتا ہے۔ 1000 ریکارڈ ایک ایک کرکے ڈالنے میں تقریباً 1 سیکنڈ کا اوور ہیڈ ہوتا ہے۔ وہی 1000 ریکارڈ ایک ہی ٹرانزیکشن میں تقریباً 5-10 ملی سیکنڈ لیتے ہیں۔ فرق اس طرح بیان کیا گیا ہے کہ ہر انفرادی INSERT سنکرونس ڈسک رائٹنگ کے ساتھ ایک نیا ٹرانزیکشن بناتا ہے۔

کارکردگی PRAGMA

PRAGMA لائبریری کے رویے کو ترتیب دینے کے لیے SQLite کمانڈز ہیں۔ اہم اصلاح پراگما: PRAGMA synchronous=NORMAL (fsync فریکوئنسی کم کرتا ہے), PRAGMA cache_size=-8000 (8 MB کیشے مختص کرتا ہے), PRAGMA temp_store=MEMORY (میموری میں عارضی ٹیبلز)۔ بڑے ڈیٹا والیوم والی موبائل ایپلیکیشنز کے لیے، ان پراگما کا امتزاج سوالات کو 2-3 گنا تیز کرتا ہے۔

ایک اور اہم اصلاح SQL سوالات کی پری کمپائلیشن (prepared statements) ہے۔ اگر کوئی سوال بار بار عملدرآمد ہوتا ہے (مثال کے طور پر، 10000 قطاریں ڈالنا)، SQL کو ایک بار کمپائل کرنا اور پھر اسٹیٹمنٹ کو دوبارہ استعمال کرنا CPU لوڈ کو 30-50% کم کرتا ہے۔ Room اور GRDB خود بخود prepared statements کو کیش کرتے ہیں، لیکن براہ راست SQLite C API استعمال کرتے وقت، کمپائلیشن دستی طور پر کی جانی چاہیے۔

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

withTransaction کے ساتھ بیچ انسرٹ یقینی بناتا ہے کہ تمام INSERT آپریشنز ایک ہی ٹرانزیکشن کے اندر عملدرآمد ہوں۔ چنکنگ (chunked) کے ذریعے ذیلی بیچوں میں تقسیم ایک ٹرانزیکشن کو بہت بڑا ہونے سے روکتی ہے، جو دوسرے تھریڈز کو طویل عرصے تک روک سکتی ہے۔ بیک گراؤنڈ سنکرونائزیشن کے لیے، 500 ریکارڈ کا ذیلی بیچ سائز رفتار اور UI ردعمل کا بہترین توازن فراہم کرتا ہے۔