পোস্টটি পড়া হয়েছে 5,672 বার
android sqlite tutorial in bengali

Android SQLite Database Tutorial [Introduction] – 1

Hasan Abdullahঅ্যান্ড্রয়েড অ্যাপ ডেভেলপমেন্ট, Android Local Storage

Post updated on 30th March, 2018 at 06:16 am

Android App এ পরস্পর সম্পর্ক যুক্ত (relational) ডেটা স্টোর করা, প্রয়োজনের সময় ঐসব ডেটা খুঁজে বের করা, দরকার অনুযায়ী আপডেট-ডিলিট করার জন্য SQLite Database সবচেয়ে বেশি জনপ্রিয়। SQLite ছাড়াও অ্যান্ড্রয়েডে ব্যবহার উপযোগি আরো ডেটাবেজ রয়েছে। তবে এটিই সবচেয়ে বেশি পরিমাণে ব্যবহৃত হয়ে থাকে। এই পোস্টে SQLite এর উপর কিছু ব্যাসিক আলোচনা আর পরের পোস্টে implementation দেখানোর চেষ্টা করব। এই পোস্টটি প্রথম প্রকাশিত হয় আমাদের মিডিয়ামের প্রোগ্রামিং পাতা থেকে।

History of SQLite

SQLite database ডেভেলপ করেন D. Richard Hipp. এটি রিলিজ করা হয় ২০০০ সালের ১৭ অগাস্ট। SQLite database-কে ডেভেলপ করার জন্য ব্যবহার করা হয় C প্রোগ্রামিং ল্যাঙ্গুয়েজ। ২০০০ সালে রিচার্ড যখন SQLite database রিলিজ করেন তখন তিনি কাজ করতেন General Dynamics এ। এটি মূলত সমরাস্ত্র, যুদ্ধ জাহাজ ইত্যাদির বিজনেস করে। রিচার্ড হিপের ডেভেলপ করা সফটওয়্যার তাদের যুদ্ধজাহাজে ব্যবহৃত হত।

Why SQLite Database in Android?

আমরা অনেক ডেটাবেজের কথা জানি। বেশির ভাগ প্রোগ্রামারের প্রথম পরিচয় হয় MySQL database এর সাথে, ওয়েবে এর প্রচুর ব্যবহার এবং ওপেন সোর্স হওয়ার কারণে। এছাড়াও PostgreSQL, Oracle Database, SQL Database, MongoDB ইত্যাদি ডেটাবেজের নাম আমরা জানি। সব রেখে কেন Android App এ SQLite database ব্যবহার করা হয়? কোড শুরু করার আগে নিচে এর কারণগুলো ব্যাখ্যা করা দরকার।

Lightweight

বেশির ভাগ Database Management System এর জন্য সার্ভার প্রয়োজন হয়। সার্ভারে ডেটাবেজ থাকবে এবং আমাদের অ্যাপ্লিকেশন প্রয়োজন অনুযায়ী সেখান থেকে ডেটা নিয়ে এসে কাজ করবে। অন্যান্য ডেটাবেজের সাথে আমাদের SQLite এর মূল পার্থক্য এখানেই। অ্যান্ড্রয়েড অ্যাপ ডেভেলপার পজিশনের জন্য জব ইন্টারভিউয়ের এটা একটা কমন প্রশ্ন যে MySQL আর SQLite এর মধ্যে পার্থক্য কী? মোবাইল অ্যাপে MySQL ইউজ না করে SQLite ইউজ করা হয় কেন? প্রথমবার শুনতে যতটা ভয়ংকর মনে হয় এর উত্তর ততটাই সোজা সাপটা। MySQL আর SQLite এর মধ্যে মূল পার্থক্য হচ্ছে MySQL আলাদা সার্ভারে বা স্ট্যান্ডঅ্যালোন প্রসেস হিসেবে রান করতে হয়, কিন্তু SQLite অ্যাপ এর মধ্যেই রান করা যায়। অর্থাৎ, MySQL আলাদাভাবে রান করে সেটার সাথে আমাদের অ্যাপকে কানেক্ট করতে হয়, সাধারণত এই ডাটাবেজ সার্ভারটা কোন একটা রিমোট লোকেশনে থাকে। কিন্তু SQLite এর ডাটাবেজ এঞ্জিন অ্যাপের মধ্যে থেকেই শুধুমাত্র একটা লাইব্রেরী হিসেবে রান হয়। একারণে SQLite কে embedded database ও বলে।
সার্ভার ছাড়া একটা ডেটাবেজ কেন আমাদের দরকার? মোবাইল অ্যাপে একটা সার্ভার টাইপ কিছু ইন্সটল করে কি MySQL ইউজ করা যায় না? তাতে সমস্যা কী?
সমস্যা হচ্ছে মোবাইল ফোনের রিসোর্সের সীমাবদ্ধতা। ডাটাবেজ সার্ভার আলাদাভাবে রান করলে তার জন্য CPU, RAM ও Power ইউজ হবে। মূলত ফোনের ব্যাটারি ও রিসোর্স ইউজ কমানোর জন্যেই আমরা ফোনে কোনো ডাটাবেজ সার্ভার রান করি না।

Optimized for single user

MySQL বা অন্যান্য ডেটাবেজে কোনো ডেটা রিড-রাইট করার সময় username-password দিয়ে authentication check করা হয়। সেটা সার্ভারসাইড যে কোনো ডেটাবেজের ক্ষেত্রে জরুরি। কিন্তু কোনো একটা মোবাইল অ্যাপ একজন ইউজারই ইউজ করেন। আমাদের অ্যাপ প্রতিটা ডিভাইসে যখন ইন্সটল হয় তখন (প্রয়োজনের সময়) সেখানে একটা ডেটাবেজ তৈরি হয়। যদি ১০০ টা ডিভাইসে অ্যাপ ইন্সটল হয় তাহলে ১০০ টা ডিভাইসেই ডেটাবেজ তৈরি হবে। কিন্তু MySQL এর ক্ষেত্রে ১০০ জন ইউজার যখন সেখানে হিট করবে ডেটাবেজ কিন্তু একটাই থাকবে। যেহেতু বিভিন্ন অ্যাপ থেকে বিভিন্ন API এর মাধ্যমে MySQL ডেটাবেজের অ্যাক্সেস করতে হয় তাই প্রতিটা রিকোয়েস্টেই চেক করার দরকার হয় রিকোয়েস্টটা যে আসছে সেটা ভ্যালিড সোর্স থেকে আসছে কিনা। অপরপক্ষে মোবাইলে থাকা ডেটাবেজটা ঐ মোবাইলের ইউজারই শুধু ইউজ করেন। তাই প্রতিবার ডেটাবেজে রিড-রাইটের সময় username-password দিয়ে authentication check করা প্রয়োজন হয় না।

Stable

SQLite ডেটাবেজটা amazingly stable. অনেক বেশি ম্যাচিউরড। সেই ২০০০ সাল থেকে billions of project এ এটা ইউজ হয়েছে। ধারনা করা হয় এই ডেটাবেজই সবচেয়ে বেশিবার deploy হয়েছে। SQLite ওপেন সোর্স প্রোজেক্ট হওয়ায় যে কেউ এর সোর্স কোড দেখতে পারে। তাই পর্যাপ্ত টেস্টিং এর মধ্য দিয়েই প্রতিটা ভার্সন রিলিজ হয়। SQLite-কে ছোটখাটো ডেটাবেজ মনে করলেও এতে database transaction এর মত ফিচার রয়েছে। অর্থাৎ আপনার ডেটাবেজ আপডেট করার পর যদি কোনো ঝামেলা হয়, আপনি আপনার আগের ভার্সনের ডেটা সহ ডেটাবেজ ফেরত পাবেন। অনেকেরই জিজ্ঞাসা থাকে যে একটা SQLite database এ সর্বোচ্চ কতটুকু ডেটা স্টোর করা যায়? SQLite এর অফিসিয়াল সাইট থেকে জানা যায় একটা SQLite database এ সর্বোচ্চ 140 terabytes ডেটা স্টোর করা সম্ভব! আর একটা row তে সম্ভব সর্বোচ্চ 1 GB ডেটা!

Fast

SQLite ডেটাবেজে কেবলমাত্র একটা flat file থাকে যেখানে সকল ডেটা store হয়। এখানে ডেটা রিড-রাইট করতে তুলনামূলক কম ব্যাটারি পাওয়ার ও CPU process খরচ হয়। নরমাল একটা ফাইলে ডেটা রিড-রাইট করার চেয়ে SQLite এ ডেটা রিড-রাইট করা বেশি faster. অন্যান্য ডেটাবেজে অনেক অনেক ফাইল থাকে। যেগুলো মেইনটেইন করার জন্য ইন্টার্নাল অনেক কাজ করতে হয়। কিন্তু SQLite database এ সেরকম কোনো জটিলতা না থাকায় অনেক দ্রুত কাজ হয়। এই ডেটাবেজটা ডেভেলপ করা হয়েছে optimized সি কোড দিয়ে। এতে করে প্রসেসিংগুলো অনেক দ্রুত হয় আর পাওয়ারও অনেক কম খরচ হয়।

Where SQLite Database is stored in Android App?

android sqlite tutorial in bengali
SQLite database file structure with directory

Android App যখন ইন্সটল হয় তখন এর cache ডেটা স্টোর করার জন্য automatically একটা ডিরেক্টরি তৈরি হয়। SQLite database এর ফাইলও এই ডিরেক্টরিতেই স্টোর হয়। আমাদের অ্যাপের package name যদি com.hellohasan.sqlite_project হয় আর ডেটাবেজের নাম যদি হয় student-db হয় তাহলে আমাদের ডেটাবেজ ফাইলের path হবেঃ

/data/data/com.hellohasan.sqlite_project/databases

database ফোল্ডারের ভিতরে দুইটি ফাইল তৈরি হবে। প্রথমটি হচ্ছে আমাদের ডেটাবেজ ফাইল। এই ফাইলেই আমাদের যাবতীয় ডেটা স্টোর হবে। আমরা জাভা কোডে ডেটাবেজের যেই নাম দিব এই ফাইলের নামও সেটাই হবে। আর দ্বিতীয় ফাইলের নাম হবে আমাদের ডেটাবেজের নাম এরপর হাইফেন দিয়ে suffix আকারে থাকবে journal. এই জার্নাল ফাইলে ডেটাবেজে আমরা যেসকল চেঞ্জ করি সেগুলোর ট্র্যাক থাকে। যদি কোনো চেঞ্জের কারণে অ্যাপে ঝামেলা হয় আর আমরা আগের ডেটাবেজে rollback করতে চাই তখন এই student-db-journal ফাইলে থাকা backup থেকে আগের অবস্থানে ফিরে যাওয়া যায়।

ORM (Object Relational Mapping) for Android

SQLite ব্যবহার করে আমরা নিজেদের মত SQL query লিখে ডেটাবেজ বানানো, টেবিল বানানো, ডেটা read-write-update-delete সব কিছু করতে পারি। SQL query লিখে কাজ করলে ডেটাবেজের সম্পূর্ণ নিয়ন্ত্রন আমাদের হাতে থাকে বা আমরা ম্যানুয়ালি প্রতিটা কাজ করাতে ঠিকঠাক বুঝতে পারি আসলে কী হচ্ছে? ORM বা Object Relational Mapping হচ্ছে এমন একটা র‍্যাপার (wrapper) লাইব্রেরী যা আপনাকে কষ্ট করে কোয়েরি(query) লেখার ঝামেলা থেকে বাঁচাবে। আপনি নরমাল OOP তে যেভাবে ক্লাস-অবজেক্ট নিয়ে ডিল করেন সেভাবেই সব কাজ করবেন। ডেটা স্টোর করা, আপডেট করা থেকে শুরু করে সব কিছুই করবেন অবজেক্ট লেভেলে। অর্থাৎ আপনার কাছে মনে হবে মেথড কল-টল করে আপনি কোনো একটা অবজেক্ট ক্রিয়েট করেছেন বা আপডেট করেছেন। কিছু annotation বা নির্দিষ্ট সিনট্যাক্স ইউজ করে কুয়েরি লিখা ছাড়াই ডেটাবেজের ডেটা নিয়ে কাজ করতে পারবেন। ORM তাহলে কী করছে? ORM আসলে ভিতরে ভিতরে SQLite-কেই ইউজ করছে। আপনি হয়ত ORM এর insert() মেথড কল করেছেন। Under the hood, ORM আপনার অবজেক্টের ডেটাগুলো parse করে ইনসার্ট করার জন্য SQL query-ই execute করেছে। ORM আমাদের কাজকর্ম অনেকখানি কমিয়ে দেয়। তবে শুরুতে কাজ করার জন্য raw SQLite ইউজ করাই ভাল। তাহলে ডেটাবেজটা ভাল মত feel করা সম্ভব হয় আর কিছু SQL query-ও শেখা হয়।

Android এর জন্য কয়েকটা ORM এর নাম নিচে দেয়া হলোঃ

Some SQLite Alternatives for Android

SQLite সবচেয়ে বেশি ব্যবহৃত আর সবচেয়ে বেশি জনপ্রিয় হলেও আমরা চাইলে অন্যান্য কিছু অল্টারনেটিভ ডেটাবেজ ইউজ করতে পারি। মনে রাখতে হবে “best programming language” এর মত “best database” বলেও আসলে কিছু নাই। সব লাইব্রেরি আর ডেটাবেজেরই কিছু সুবিধা আর কিছু অসুবিধা রয়েছে। একেক ল্যাঙ্গুয়েজ ডেভেলপ করার পেছনে যেমন একেকটা উদ্দেশ্য বা কিছু key point কাজ করে, একই রকম ভাবে যে কোনো ডেটাবেজের ক্ষেত্রেও কথাটা সত্যি। নতুন একটা ডেটাবেজ ডেভেলপ করার সময় যেই পয়েন্টগুলোর উপর ভিত্তি করে ডেভেলপ করার কথা চিন্তা করা হয় সেগুলোকে মেজর টাস্ক হিসাবে রাখা হয়। ফলে বাদ বাকি কিছু পয়েন্টে হয়ত কিছু compromise করতে হয়। তাই ইউজ করার সময় আমাদের অ্যাপের requirement অনুযায়ী প্রতিটা ডেটাবেজের pros-cons নিয়ে অ্যানালাইসিস করে সিদ্ধান্ত নিতে পারি।

আমি পারসোনালি এখন পর্যন্ত শুধু SQLite নিয়েই কাজ করেছি। অন্যান্য ডেটাবেজ নিয়ে আগামীতে কাজ করার ইচ্ছা আছে। নিচে কয়েকটা SQLite alternative এর নাম দেয়া হলোঃ

অনাকাংখিত ভাবেই পোস্টের সাইজটা বেশ বড় হয়ে গেল। তাই আর এই পোস্টে কোড করা শুরু করলাম না। ইনশাঅাল্লাহ, পরের পোস্টে Android App এ SQLite database তৈরি করা দেখাব। পরের পর্বটি পড়তে পারেন এখান থেকে।