انتخاب پایگاه داده مناسب برای اپلیکیشن فلاتر | راهنمای کاربردی

انتخاب یک دیتابیس برای هر اپلیکیشنی به عوامل مختلفی وابسته است. امروزه گزینه‌های زیادی نیز در این زمینه وجود دارند که می‌توانید از میان آن‌ها انتخاب کنید. در این مقاله با روش انتخاب پایگاه داده مناسب برای اپلیکیشن فلاتر آشنا خواهیم شد.

انواع مختلف پایگاه‌های داده به طور عمده در یکی از سه دسته زیر قرار می‌گیرند:

• پایگاه‌های داده رابطه‌ای: این دسته از پایگاه‌های داده شامل انواع سنتی دیتابیس‌ها هستند. این نوع از دیتابیس‌ها داده‌ها را ذخیره نمی‌کنند، بلکه رابطه بین آن‌ها را نگهداری می‌کنند. SQLite یک نمونه از پایگاه‌‌های داده رابطه‌ای است.
• پایگاه‌های داده NoSQL: این نوع از دیتابیس‌ها داده‌ها را به صورت «اسناد» (Documents) ذخیره می‌کنند. در این دسته از پایگاه‌های داده استفاده از یک «اسکیما» (Scema) همانند دیتابیس‌های رابطه‌ای الزام نشده است. این نوع از دیتابیس‌ها بسیار سریع هستند و می‌توانند بخش‌های عظیمی از داده‌های غیر ساخت‌یافته را به خوبی مدیریت کنند. MongoDB نمونه‌ای از یک پایگاه داده NoSQL است.
• ذخیره داده منفرد: با این که این گزینه از نظر فنی در دسته پایگاه‌های داده قرار نمی‌گیرد، اما شما ملزم به استفاده از یکی از گزینه‌های فوق نیستید. شما می‌توانید داده‌ها را در یک فایل JSON ذخیره کنید و سریا‌ل‌سازی و سریال‌زدایی آن‌ها را خودتان مدیریت کنید. این روش می‌تواند به طرز خارق‌العاده‌ای سریع باشد، اما در صورتی که مهارت بالایی در برنامه‌نویسی نداشته باشید، ممکن است برخی باگ‌های عجیب ایجاد کنید.

در انتهای این مقاله شما با موارد زیر آشنا خواهید بود:

• مبانی طرز کار پایگاه‌های داده.
• شیوه راه‌اندازی هر پایگاه داده.
• کاربردهای مناسب هر نوع پایگاه داده.

بخش‌های این مقاله بر اساس دسته‌بندی‌های فوق‌الذکر پایگاه‌های داده تنظیم شده‌اند.

پایگاه‌های داده رابطه‌ای

پایگاه‌های داده رابطه‌ای از مدت‌ها پیش و از دهه 1970 وجود دارند.

در این بخش برخی از گزینه‌های رابطه‌ای که امروزه برای اپلیکیشن‌های فلاتر مطرح هستند را بررسی می‌کنیم.

SQflite

SQflite (+) یک پیاده‌سازی از SQLite برای فلاتر است. این سیستم کنترل کاملی روی پایگاه داده، کوئری‌ها، ‌رابطه‌ها و همه موارد لازم دیگر به دست می‌دهد. در یک اپلیکیشن فلاتر روش تعامل با پایگاه داده SQflite به صورت زیر است:

کوئری‌ها نیز به صورت زیر انجام می‌گیرند:

مزایای SQflite

• کنترل کامل روی پایگاه داده وجود دارد.
• در صورتی که هم اینک با SQLite آشنا باشید، یک پایگاه داده کاملاً کارآمد SQLite برای اپلیکیشن شما محسوب می‌شود.
• به صورت آسانی از سوی اپلیکیشن‌های شخص ثالث که بتوانند پایگاه‌های داده SQLite را بخوانند باز می‌شود و از این رو می‌توانید پایگاه داده خود را روی رایانه بخوانید و داده‌ها را بررسی کنید.

معایب SQflite

• نوشتن همه کوئری‌ها به صورت دستی به زمان زیادی نیاز دارد.
• داده‌های بازگشتی از پایگاه داده از آغاز دارای نوع‌بندی قوی نیستند.
• مدیریت میگریشن‌ها روی دستگاه کاری بالقوه دشوار است به خصوص زمانی که اسکیما بین به‌روزرسانی نسخه‌ها عوض شود، این مسئله مشهودتر خواهد بود.
• از وب پشتیبانی نمی‌کند.

کاربردهای SQflite

SQflite برای استفاده روی داده‌های رابطه‌ای مناسب است، اما کنترل کاملاً دقیقی روی کوئری‌های واقعی نیز به دست می‌دهد. در زمان استفاده از SQflite نوشتن کوئری‌های خاص کاری کاملاً آسان است و نیازی به فکر و تأمل زیاد ندارد.

تجریدهای SQLite

استفاده مستقیم از SQLite برای مدیریت اپلیکیشن‌ها می‌تواند گزینه‌ای کاملاً قدرتمند باشد، اما در عین حال سنگین نیز هست. به همین دلیل است که راهکارهای مختلفی برای تجرید برخی از کارکردها از SQLite به صورتی ساده و کارآمد ارائه شده است. این تجریدها می‌توانند کار با پایگاه‌های داده SQLite را آسان‌تر سازند و در عین حال مزیت استفاده از SQLite را نیز حفظ کنند.

فیلم آموزش ساخت اپلیکیشن مدیریت یادداشت ها در اندروید استودیو با SQLite در فرادرس

کلیک کنید

Floor (+) و Moor (+) دو گزینه محبوب از این رویکرد محسوب می‌شود. ما در این مقاله به بررسی Moor می‌پردازیم، اما رویکردی که این دو پکیج برای تجرید SQLite استفاده می‌کنند، تقریباً کاملاً مشابه است.

Moor

برای استفاده از Moor باید پکیج Moor را از flutter pub (+) ایمپورت کنید، اما در کنار آن باید چیز دیگری به نام moor_generator را نیز ایمپورت کنید. این مورد دوم از سوی build_runner برای تولید کد مورد استفاده پایگاه داده، استفاده می‌شود.

شاید بپرسید چرا باید از build_runner استفاده کنیم؟ build_runner به طور عمده برای تولید کدی استفاده می‌شود که در پروژه‌های فلاتر کاربرد دارد. در محیط‌های غیر از فلاتر ما به ندرت از ابزارهای تولید کد استفاده می‌کنیم، زیرا بسیاری از زبان‌های دیگر برنامه‌نویسی مانند C# از چیزی به نام Reflection پشتیبانی می‌کنند.

به بیان ساده این کار به فریمورک امکان می‌دهد که به صورت دینامیک بخش‌هایی از برنامه را در runtime فراخوانی کند. این ابزاری قدرتمند است، اما به طور معمول کُند عمل می‌کند. همچنین روی linking اپلیکیشن تولید شده تأثیر می‌گذارد، چون مانند Reflection هر بخش از اپلیکیشن از نظر فنی باید قابل دسترسی یا استفاده باشند.

زمانی که پکیج‌ها از کارکردی استفاده می‌کنند که به طور معمول از سوی Reflection ارائه می‌شود، غالباً از build_runner برای تولید کدهای لازم به صورت پیش‌دستانه استفاده می‌کنند. در نتیجه کدی با اجرای سریع در runtime به دست می‌آید و همچنین امکان tree shaking یا کاهش حجم باینری اپلیکیشن در زمان توزیع، بهبود می‌یابد.

با نگاهی به مستندات سرآغاز (+) متوجه می‌شویم که یک پایگاه داده چگونه ساخته می‌شود:

Moor به صورت برنامه‌نویسی‌شده، اسکیما را برای جدول‌ها بسته به شیوه تعریف محتوایشان ایجاد می‌کند. در ابتدای نمونه کد فوق می‌بینیم که گزاره part وجود دارد. زمانی که دستور build_runner را اجرا کنیم، Moor اسکیما را بر مبنای آن چه در این فایل تعریف کرده‌ایم تولید می‌کند. همچنین می‌توانید هر زمان در صورت نیاز به اجرای یک کوئری خاص یا در صورتی که بخواهید کنترل دقیق‌تری داشته باشید، به SQL خام بازگردید.

مزایای Moor

• نتایج ارائه شده دارای نوع‌بندی قوی هستند.
• بر مبنای SQLite عمل می‌کند.
• لازم نیست هر کوئری را به صورت دستی خودتان بنویسید.
• بخش زیادی از کار بر عهده تولید کد خودکار است.
• پایگاه‌های داده SQLite می‌توانند با طیف وسیعی از ابزارهایی که هم اینک موجود هستند باز شوند و داده‌ها در زمان توسعه بررسی شوند.

معایب Moor

• مدیریت به‌روزرسانی‌های اسکیما روی دستگاه لوکال کار دشواری است.
• پشتیبانی وب همچنان در حالت پیش‌نمایش است.
• وابستگی‌های خاص پلتفرم دارد (به طور کامل در Dart نوشته نشده است).

کاربردهای Moor

اگر به داده‌های رابطه‌ای نیاز دارید و هم‌زمان می‌خواهید در حد امکان SQL کمی بنویسید، این گزینه برای شما مناسب خواهد بود.

پایگاه‌های داده NoSQL

برای استفاده از پایگاه‌های داده NoSQL در اپلیکیشن‌های فلاتر گزینه‌های چندان زیادی وجود ندارند.

برخی گزینه‌های محبوب مانند فایربیس (Firebase) وجود دارند که مدت‌ها است معرفی شده‌اند و برخی راهکارهای جدیدتر مانند Hive نیز ارائه شده‌اند. فایربیس و هایو تفاوت‌های زیادی دارند، اما شاید مهم‌ترین تفاوت آن‌ها این است که فایربیس می‌تواند با یک استور آنلاین همگام‌سازی شود، در حالی که Hive بیشتر برای ذخیره لوکال داده‌ها روی دستگاه مناسب است.

فایربیس: ذخیره آنلاین NoSQL

فایربیس یک پایگاه داده سنتی ذخیره سند است. به این ترتیب داده‌ها به صورت Collection-هایی ذخیره می‌شوند که به جدول در پایگاه‌‌های داده سنتی شبیه هستند. این کالکشن‌ها اسناد (Documents) ‌را در خود ذخیره می‌کنند. اسناد انواع داده مختلف مانند string ،int و غیره را نگهداری می‌کنند. همچنین می‌توانند یک لینک به سند دیگر را نیز ذخیره کنند. از این رو با این که فایربیس یک پایگاه داده رابطه‌ای به صورت صریح نیست، اما می‌توانید رابطه‌هایی بین داده‌ها برقرار کنید.

راه‌اندازی فایربیس در قیاس با گزینه‌های روی دستگاه لوکال مانند Moor یا Hive کاملاً پیچیده است، اما امکان همگام‌سازی داده‌ها بین کلاینت‌ها و سرور را فراهم می‌سازد. این بدان معنی است که اگر چند کلاینت در یک اپلیکیشن داشته باشید و بخواهید همه آن‌ها روی داده‌های مشترکی کار کنند، این داده‌ها می‌توانند بین کلاینت‌ها همگام‌سازی شوند. ضمناً این تنظیمات در آزمایشگاه کد گوگل (+) به طور کامل توضیح داده شده است. تنها عیب این رویکرد آن است که داده‌های با نوع‌بندی قوی را همانند Moor یا Hive نخواهید داشت و خودتان باید این موضوع را مدیریت کنید.

مزایای فایربیس

• همگام‌سازی با ذخیره آنلاین فایربیس به صورت تقریباً آنی (near real-time).
• پشتیبانی خوب از ابزارهای مختلف.
• جستجوی ساده داده‌های آنلاین از طریق کنسول فایربیس.

معایب فایربیس

• در صورتی که از قبل فایربیس با به اپلیکیشن خود اضافه نکرده باشید، تنظیم فایربیس می‌تواند دشوار باشد.
• از آنجا که فایربیس یک پایگاه داده آنلاین است، باید در مورد چیزهایی مانند مجوزهای دسترسی، توجه بسیار بیشتری داشته باشید.
• پشتیبانی فایربیس از فلاتر هنوز در حالت آماده پروداکشن نیست.

کاربردهای فایربیس

اگر داده‌های شما بین دستگاه‌های مختلفی گسترده شده‌اند و به یک همگام‌سازی (نسبتاً) بی‌دردسر بین این دستگاه‌ها نیاز دارید، فایربیس راهکار مناسبی برای شما خواهد بود.

Hive: ذخیره آفلاین NoSQL

Hive یک گزینه ذخیره‌سازی بسیار سریع NoSQL برای توسعه‌دهندگان فلاتر است. بزرگ‌ترین مزیت این سیستم این است که کاملاً بومی Dart است. این بدان معنی است که هر جایی که دارت کار کند، هایو نیز می‌تواند عمل کند، چون نیازمند هیچ پیاده‌سازی خاص دستگاه نیست.

فیلم آموزش پروژه محور فلاتر – ساخت اپلیکیشن خبری برای Android با Flutter در فرادرس

کلیک کنید

Hive امکان ذخیره‌سازی داده‌ها را به صورت یک HiveObject می‌دهد. به این ترتیب می‌توانیم برخی روابط را بین شیء‌ها نیز ذخیره کنیم. هایو اشیا را در یک box ذخیره می‌کند، اما می‌توانیم TypeAdapter-هایی برای آن‌ها ایجاد کنیم.

دریافت یک box کار آسانی است:

خواندن و نوشتن آن نیز آسان است:

اما نقطه اصلی مزیت Hive امکان تولید TypeAdapter-ها است. برای کسب اطلاعات بیشتر در این خصوص به این صفحه از مستندات (+) مراجعه کنید. به این ترتیب نوع‌بندی قوی در Box-ها ایجاد می‌شود و می‌توان کلاس‌ها را در آن‌ها ذخیره ساخت و همچنین در Box-های دیگر به اشیا ارجاع داد. در مستندات هایو با روش ایجاد یک باکس بر مبنای یک کلاس با تعریف سفارشی به صورت زیر آشنا می‌شویم:

همچنان که در کد فوق می‌بینید، این کلاس شامل یک List از Person است و از این رو Hive می‌تواند به لیستی از اشیا ارجاع دهد.

کاربردهای Hive

اگر صرفاً به دنبال یک پایگاه داده ساده هستید که داده‌های شما را روی دستگاه ذخیره کند و نیازی به همگام‌سازی که فایربیس ارائه می‌کند ندارید و می‌خواهید گزینه‌ای داشته باشید که در همه جا کار کند، در این صورت Hive به درد شما می‌خورد.

ساخت یک پایگاه داده سفارشی

اگر هیچ کدام از گزینه‌های که تا به اینجا معرفی کردیم، توجه شما را جلب نکرده‌اند، می‌توانید دست به ساخت پایگاه داده سفارشی خودتان بزنید. به این منظور می‌توانید از یک کتابخانه مانند json_serializable استفاده کنید و فایل‌های JSON را روی دستگاه برای دسترسی اپلیکیشن ذخیره سازید.

این کار تقریباً شبیه به ساخت یک خودروی شخصی از صفر تا صد است. البته امکان انجام این کار وجود دارد و افرادی نیز این کار را انجام می‌دهند، اما باید توجیه خوبی برای انجام آن داشته باشید. ایجاد یک پایگاه داده جدید به معنی ایجاد یک کتابخانه جدید با باگ‌های بالقوه و بسیاری مشکلات دیگر است که باید همه آن‌ها را در نظر داشته باشید. اگر قصد دارید یک اپلیکیشن بسازید، ‌آیا ساخت یک پایگاه داده سفارشی برای آن نیز در حیطه وظایف شما قرار می‌گیرد؟

راه‌حل‌های موجود مانند Hive یا Moor هم‌اینک از سوی افراد بسیار زیادی مورد استفاده قرار می‌گیرند و همه باگ‌های آن‌ها مشخص شده و مشکلاتشان روی GitHub مورد رسیدگی قرار می‌گیرد. به همین جهت است که این کتابخانه‌ها کیفیت بالایی یافته‌اند. اما در مورد پایگاه داده سفارشی تازه متولد‌شده‌ی شما، چه کسانی باگ‌های آن‌ها را کشف خواهند کرد؟ از آنجا که شما تنها کاربر این سیستم هستید، تنها خودتان می‌توانید باگ‌های آن را پیدا کنید و این موضوع چندان خوشایند به نظر نمی‌رسد.

کاربردهای پایگاه داده سفارشی

اگر به کلی به کدهایی که توسط کسی غیر از شما نوشته باشد، بی‌اعتماد هستید و یا به یک کاربرد خیلی خاص نیاز دارید، شاید ساخت پایگاه داده سفارشی هم یکی از گزینه‌های روی میز برای شما باشد. اما در هر صورت این یک تصمیم مهم است و باید همه جوانب آن را در نظر بگیرید.

از میان همه این گزینه‌ها کدام را باید انتخاب کرد؟

راه ساده‌ای برای پاسخ به این سؤال که بهترین پایگاه داده کدام است وجود ندارد. همه چیز به کاربرد شما بستگی دارد. در ادامه برخی موارد را جمع‌بندی می‌کنیم.

• اگر داده‌های شما به صورت رابطه‌ای هستند و می‌خواهید در زمان توسعه، امکان دیدن آن‌ها را به سادگی روی رایانه‌تان داشته باشید، و پشتیبانی از وب نیز برایتان مهم نیست، در این صورت از Moor استفاده کنید.
• اگر لازم است که داده‌هایتان بین دستگاه‌های مختلف، همگام‌سازی شود و تنظیمات ابتدایی پیچیده برایتان مهم نیست، از فایربیس استفاده کنید.
• اگر می‌خواهد همه چیز را به سرعت راه‌اندازی و مورد استفاده قرار دهید و پشتیبانی خوبی از وب و همه چیزهایی که دارت روی آن‌ها اجرا می‌شود، داشته باشید، در این صورت از Hive استفاده کنید.
• اگر تردید جدی و مهمی در مورد امنیت این پایگاه‌های داده دارید و هیچ کس نمی‌تواند شما را قانع سازد و زمان زیادی نیز در اختیار دارید؛ می‌توانید یک پایگاه داده سفارشی با استفاده از اشیای JSON برای خود بسازید.

سخن پایانی

در نهایت باید اشاره کنیم که به طور کلی در اغلب کاربردهای اپلیکیشن‌های فلاتر، پایگاه داده Hive برای رفع نیازهای شما کافی خواهد بود.

فیلم مجموعه آموزش جاوا اسکریپت JavaScript – مقدماتی تا پیشرفته در فرادرس

کلیک کنید

امیدواریم این مقاله با موضوع انتخاب بهترین پایگاه داده برای اپلیکیشن فلاتر مورد توجه شما قرار گرفته باشد.