Data-mapper ORM for Typescript and MySQL
مقایسه بین MySQL 5.6 و Firebird SQL 2.5 
اخر سر من نفهمیدم مصلا به سر سایتهایی که از Mysql استفاده می کنند چی پیش میاد
- الگوهای ابتدایی برای برنامه نویسی دات نت | www.dotnetdev.info
- امنیت Android مبتنی بر هسته لینوکس، آنچنان هم تعریفی ندارد | www.winbeta.net
- معرفی StimulReport نسخه Silverlight با ساپورت RightToLeft | www.nikamooz.com
- Wintellect's Power Collections for .NET | powercollections.codeplex.com
- DFA/NFA for .NET | github.com
- Doom 3 GPL source code | github.com
- Visual Studio Achievements | channel9.msdn.com
- امکان یکپارچگی Atmel AVR Studio 5 با ویژوال استودیو | channel9.msdn.com
- شروع به کار با MongoDB | net.tutsplus.com
- طرح Visual Studio Achievements و توجه به کیفیت کدهای ارائه شده | hadihariri.com
- کتابی رایگان در مورد Razor View Engine | www.kunal-chowdhury.com
- لیستی از کتابخانه‌های رایگان مفید مرتبط با دات نت فریم ورک | stackoverflow.com
- مقایسه‌ای بین Silverlight و HTML5 | channel9.msdn.com
در این مقاله با دو سیستم
کنترل نسخه git و SVN آشنا شده و تفاوت‌های آنها را برای تازه‌کاران بررسی میکنیم. ایده
اولیه نوشتن این مقاله زمانی بود که برای یک پروژه‌ای، اعضای تیم ما دور هم
جمع شده و در مورد ابزارهای مورد استفاده بحث کردند و یک عده از گیت و
عده‌ای از SVN صحبت می‌کردند. بر این شدم که مقاله‌ای نوشته و ابتدا به
معرفی آنها و سپس به مزایا و معایب هر کدام بپردازیم.
امروزه، استفاده از سیستم‌های کنترل نسخه ( Version Control System
) رواج زیادی پیدا کرده است. این سیستم‌ها به شما اجازه می‌دهند تا
تغییراتی را که در پروژه ایجاد میشوند، ضبط و ثبت کرده تا از تغییراتی که در
سطح پروژه اتفاق می‌افتد آگاه شوید. با ذکر یک نمونه این تعریف را باز
میکنم:
شما
به صورت تیمی در حال انجام یک پروژه هستید و باید نسبت به تغییراتی که
اعضای تیم در یک پروژه می‌دهند، آگاه شوید. هر برنامه نویس بعد از انجام
تغییرات باید این تغییرات را در سیستم کنترل نسخه به روز کند تا بتوان به
سوالات زیر پاسخ داد:
آیا اگر در
بین راه به مشکل برخوردید میتوانید پروژه خود را به یک یا چند گام عقب‌تر
برگردانید؟ آیا میتوانید به هر یک از اعضاء تیم دسترسی‌هایی را به قسمت
هایی از پروژه تعیین کنید؟ میتوانید تفاوت فایل‌های تغییر یافته را
بیابید؟ آیا میتوان خطاهای یک برنامه را گزارش داد و به بحث در مورد آن پرداخت؟
چه کسی کدها را تغییر داده است؟ روند کار و تغییرات به چه صورت است؟ (این
مورد برای به روز کردن نمودارهای burndown در توسعه چابک میتواند بسیار مفید باشد.)
پی نوشت: نه تنها در یک تیم بلکه بهتر هست در یک کار انفرادی هم از این سیستم‌ها استفاده کرد تا حداقل بازبینی روی پروژه‌های شخصی خود هم داشته باشیم.
سیستم
کنترل گیت: این سیستم در سال 2005 توسط لینوس توروالدز خالق لینوکس معرفی
شد و از آن زمان تاکنون یکی از پر استفاده‌ترین سیستم‌های کنترل نسخه شناخته
شده است. ویکی پدیا گیت را به این شکل تعریف میکند: «یک سیستم بازبینی توزیع شده با تاکید بر جامعیت داده‌ها، سرعت و پشتیبانی جهت توزیع کار.»
از معروف‌ترین سیستم‌های هاستینگ که از گیت استفاده میکنند، میتوان به گیت هاب اشاره کرد.
اکثر سیستم‌های هاستینگ گیت، دو حالت را ارائه می‌دهند:
عمومی : در
این حالت کدهای شما به عموم بازدیدکنندگان نمایش داده میشود و دیگران هم
میتوانند در تکمیل و ویرایش کدهای شما مشارکت کنند و این امکان به صورت
رایگان فراهم است. سیستم گیت هاب به دلیل محبوبیت زیادی که دارد، در اکثر
اوقات انتخاب اول همه کاربران است.
خصوصی:
در این حالت کد متعلق به شما، یا شرکت یا تیم نرم افزاری شماست و غیر از
افراد تعیین شده، شخص دیگری به کدهای شما دسترسی ندارد. اکثر سیستم‌های
مدیریتی این مورد را به صورت premium پشتیبانی میکنند. به این معنا که
باید اجاره آن را به طور ماهانه پرداخت کنید. سیستم گیت هاب ماهی پنج دلار
بابت آن دریافت میکند. سیستم دیگری که در این زمینه محبوبیت دارد سیستم BitBucket هست
که که اگر تیم شما کوچک است و در نهایت پنج نفر هستید، میتوانید از حالت
خصوصی به طور رایگان استفاده کنید ولی اگر اعضای تیم شما بیشتر شد، باید
هزینه‌ب اجاره آن را که از 10 دلار آغاز می‌گردد، به طور ماهیانه پرداخت
کنید.
پی نوشت: میتوانید از سیستم‌های متن باز رایگان هم که قابل نصب بر روی هاست ها هم هستند استفاده کنید که در این حالت تنها هزینه هاست یا سرور برای شما می‌ماند.
در سیستم گیت اصطلاحات زیادی وجود دارد:
Repository یا مخزن: برای هر
پروژه‌ای که ایجاد میشود، ابتدا یک مخزن ایجاد شده و کدها داخل آن قرار
می‌گیرند. کاربرانی که قصد تغییر پروژه را دارند باید یک مخزن جداگانه ایجاد
کنند تا بعدا تمامی تغییرات آنها را روی پروژه‌ی اصلی اعمال کنند.
Fork:
هر کاربری که قصد تغییر را بر روی سورس کدی، داشته باشد، ابتدا باید پروژه‌ی نویسنده اصلی پروژه را به یک مخزنی که متعلق به خودش هست انتقال دهد. به این
عمل Fork کردن می‌گویند. حال کاربر تغییرات خودش را اعمال کرده و لازم هست
که این تغییرات با پروژه‌ی اصلی که به آن Master می‌گوییم ادغام شوند. بدین جهت
کاربر فرمان pull request را می‌دهد تا به نویسنده‌ی اصلی پروژه این موضوع
اطلاع داده شود و نویسنده‌ی اصلی در صورت صلاحدید خود آن را تایید کند.
Branching یا شاخه بندی: نویسنده‌ی مخزن اصلی میتواند با مفهومی با نام شاخه بندی کار کند. او با استفاده از
این مفهوم، پروژه را به قسمت یا شاخه‌های مختلف تقسیم کرده و همچنین با
ایجاد دسترسی‌های مختلف به کاربران اجازه تغییرات را بدهد. به عنوان مثال
بخش‌های مختلف پروژه از قبیل بخش منطق برنامه، داده ها، رابط کاربری و ...
میتواند باشد. بعد از انجام تغییرات روی یک شاخه میتوانید درخواست merge
ادغام شدن یا کل پروژه را داشته باشید. در عمل شاخه بندی، هیچ کدام از
شاخه‌های بر روی یک دیگر تاثیر یا دخالتی ندارند و حتی میتوانید چند شاخه
را جدا از بخش master با یکدیگر ادغام کنید.
به غیر از ارتباط خط فرمانی که میتوان با گیت هاب برقرار کرد، میتوان از یک سری ابزار گرافیکی خارجی هم جهت ایجاد این ارتباط، استفاده کرد:
GitHub For Windows :
نسخه‌ی رسمی است که از طرف خود گیت هاب تهیه گردیده است و استفاده از آن
بسیار راحت است. البته یک مشکل کوچک در دانلود آن وجود دارد که دانلود آن
از طریق یک برنامه‌ی جداگانه صورت گرفته و اصلا سرعت خوبی جهت دانلود ندارد.
Visual Studio .Net : (+ ) خود
ویژوال استودیو شامل سیستمی به اسم Microsoft Git Provider است که در بخش
تنظیمات میتوانید آن را فعال کنید (به طور پیش فرض فعال است) و به هر نوع
سیستم گیتی میتوانید متصل شوید. تنها لازم است که آدرس Url گیت را وارد
کنید.
SourceTree:
از آن دست برنامه‌های محبوبی است که استفاده آسانی دارد و خودم به شخصه از
آن استفاده میکنم. شامل دو نسخه‌ی ویندوز و مک است و میتوانید با چندین
سیستم گیت مثل «گیت هاب» و «بیت باکت» که در بالا به آنها اشاره شد، به طور
همزمان کار کند.
LLBLGEN یکی از ORM های تجاری بسیار با کیفیت دات نت است و علاوه بر اینکه هویت مستقلی دارد، امکان تولید کدهای مخصوص Entity framework و NHibernate را هم دارا است.
اخیرا این شرکت تصمیم گرفته است که سیستم پشتیبانی مشتریان خودش را که نمونه‌ای از آن‌را در اینجا میتوانید ملاحظه کنید، سورس باز کند.
حداقل پیشنیازهای نصب این انجمن به شرح زیر است:
- ASP.NET 2.0+
- SQL Server 2000 or higher / CE Desktop 3.5
- NET 3.5+
نصب بسیاری از نرم افزارها، کاری مشکل است
فرض کنید می‌خواهید یک فایل ویدیویی با قالب m4v را بر روی تلویزیون خود نمایش دهید؛ اما تلویزیون شما تنها از فایل‌های mp4، پشتیبانی میکند. برای رفع این مشکل نیاز به یک نرم افزار تبدیل کننده‌ی فرمت‌های ویدیویی را داریم و یکی از قوی‌ترین‌های آنها، FFmpeg است. اگر به سایت آن مراجعه کنید، لینک دانلود آن به یک فایل tar.bz2 ختم میشود که حاوی سورس آن است! هرچند در قسمتی از آن، فایل‌های نهایی کامپایل شده‌ی مخصوص سیستم عامل‌های مختلف را نیز میتوانید پیدا کنید، اما باز هم با انبوهی از لینک‌ها مواجه خواهید شد که دقیقا مشخص نیست کدام را باید دریافت کرد و آیا نگارش دریافت شده، با سیستم عامل فعلی سازگار است یا خیر.
همانطور که مشاهده میکنید، هنوز هم شروع به کار با نرم افزارهای مختلف برای بسیاری از کاربران، کاری مشکل و طاقت‌فرسا است. در اینجا شاید این سؤال مطرح شود که این موضوع چه ربطی به Docker (Docker) و کانتینرها (Containers) دارد؟ تمام هیاهویی که پیرامون Docker ایجاد شده‌است، در اصل جهت ساده سازی نصب، راه اندازی و تعامل با نرم افزارهای مختلف است.
چالش‌های پیش روی یافتن نرم افزارهای مناسب
این روزها بیشتر نرم افزارهای مورد نیاز خود را از اینترنت تهیه میکنیم. اولین مرحله‌ی آن و اولین چالشی که در اینجا وجود دارد، یافتن نرم افزاری با مشخصات مدنظر است. برای نمونه حتی اگر با FFmpeg آشنا نیز باشید، به سادگی مشخص نیست که برای سیستم عامل و معماری خاص پردازنده‌ی آن، دقیقا کدام نگارش آن‌را از چه آدرسی میتوان دریافت کرد. پس از یافتن نرم افزار و نگارش مدنظر، مرحله‌ی بعد، استخراج محتویات آن از یک فایل zip و یا اجرای برنامه‌ی نصاب آن است و مرحله‌ی آخر، اجرای این برنامه میباشد.
بنابراین اولین چالش، یافتن محلی برای دریافت نرم افزار است:
- این روزها برای بعضی از سکوهای کاری، App Storeهایی وجود دارند که میتوان از آنجا شروع کرد؛ اما چنین قابلیتی برای تمام سکوهای کاری پیش بینی نشده‌است.
- در لینوکس قابلیت دیگری به نام Package manager وجود دارد که کار یافتن و نصب نرم افزارها را ساده میکند؛ اما گاهی از اوقات اطلاعات آن، آنچنان به روز نیست. همچنین اگر بسته‌ای برای توزیع خاصی از لینوکس وجود داشته باشد، الزاما به این معنا نیست که این بسته، قابلیت استفاده‌ی در سایر توزیع‌های لینوکس را نیز به همراه دارد. در ویندوز نیز وضعیت مشخص است! فاقد یک Package manager توکار و استاندارد است. هرچند یک App Store برای آن از طرف مایکروسافت ارائه شده‌است، اما آنچنان محبوبیتی پیدا نکرده‌است.
- و روش متداول دیگری که وجود دارد، مراجعه‌ی مستقیم به سایت اصلی سازنده‌ی نرم افزار است.
- علاوه بر این‌ها داشتن یک سری متادیتا و آمار نیز در مورد نرم افزارها بسیار مفید هستند تا بتوانند در مورد تصمیم به استفاده، یا عدم استفاده‌ی از نرم افزار، راهنمای کاربران باشند؛ مانند میزان محبوبیت، تعداد بار دریافت، تعداد مشکلاتی که کاربران با آن داشته‌اند و آخرین باری که نرم افزار به روز شده‌است. اما با توجه به پراکندگی روش‌های دریافت نرم افزار که ذکر شدند، عموما یک چنین آمارهایی را مشاهده نمی‌کنیم.
- چالش دیگر، مشکل سخت اطمینان کردن به روش‌های مختلف توزیع نرم افزارها است. آیا سایتی که این نرم افزار را ارائه می‌دهد، واقعا مرتبط با نویسنده‌ی اصلی آن است؟ همچنین آیا خود نرم افزار مشکلات امنیتی را به همراه ندارد؟ چه کاری را انجام می‌دهد؟
- مشکل بعدی، در دسترس بودن سایت توزیع کننده‌ی نرم افزار است. آیا زمانیکه به برنامه‌ای نیاز داریم، پهنای باند سایت توزیع کننده‌ی آن تمام نشده‌است و میتوان به آن دسترسی داشت؟
- چالش دیگر، چگونگی پرداخت مبلغی برای دسترسی به نرم افزار است. به نظر تا به اینجا تنها App Storeها موفق شده‌اند روشی یک دست را برای خرید برنامه‌ها و همچنین ارائه‌ی مجوزی برای استفاده‌ی از آنها، ارائه دهند.
چالش‌های پیش روی نصب نرم افزارها
زمانیکه به مرحله‌ی نصب نرم افزار می‌رسیم، هر نرم افزار، روش نصب و تنظیمات آغازین خاص خودش را دارد.
- اولین چالش پس از دریافت نرم افزار، بررسی سازگاری آن با سیستم عامل و پردازنده‌ی فعلی است. شاید این مسایل برای توسعه دهندگان نرم افزارها پیش‌پا افتاده به نظر برسند، اما برای عموم کاربران، چالشی جدی به شما می‌روند.
- پس از مشخص شدن سازگاری یک نرم افزار با سیستم فعلی، قالب ارائه‌ی آن نرم افزار نیز میتوان مشکل‌زا باشد. بعضی از برنامه‌ها صرفا از طریق سورس کد منتشر میشوند. بعضی از آنها توسط یک فایل exe متکی به خود ارائه میشوند و بعضی دیگر به همراه یک فایل exe و تعدادی dll به همراه آنها. گاهی از اوقات این برنامه‌ها نیاز به نصب جداگانه‌ی NET Runtime. و یا Java Runtime را برای اجرا دارند و یا وابستگی آنها صرفا به نگارش خاصی از این کتابخانه‌ها و فریم ورک‌های ثالث است. هرچند اگر برنامه‌ای به همراه بسته‌ی نصاب آن باشد، به احتمال زیاد این وابستگی‌ها را نیز نصب میکند؛ اما تمام برنامه‌ها اینگونه ارائه نمی‌شوند. به علاوه خیلی‌ها علاقه‌ای به کار با برنامه‌های نصاب ندارند و از ایجاد تغییرات بسیاری که آنها در سیستم ایجاد میکنند، خشنود نیستند.
- پس از نصب نرم افزار، مشکل بعدی، نحوه‌ی به روز رسانی آنها است. چگونه باید اینکار انجام شود؟ (تمام مراحل و چالش‌هایی را که تاکنون بررسی کردیم، یکبار دیگر از ابتدا مرور کنید!)
بنابراین همانطور که مشاهده میکنید، نصب، راه اندازی و به روز رسانی نرم افزارها این روزها بسیار پیچیده شده‌اند و بسیاری از کاربران به سادگی از عهده‌ی آنها بر نمی‌آیند.
چالش‌های پیش روی کار با نرم افزارها
مرحله‌ی بعد، نیاز به مستندات کافی برای کار با برنامه است. این مستندات را از کجا میتوان تهیه کرد؟ آخرین باری که به روز شده، چه زمانی بوده‌است؟ بسیاری از اوقات بین مستندات تهیه شده و آخرین نگارش نرم افزار، ناسازگاری وجود دارد و به سختی قابل استفاده‌است. آیا نیاز است برنامه را به PATH اضافه کرد؟ آیا نیاز است به صورت سرویس نصب شود؟ اگر بله، چگونه باید این مراحل را انجام داد؟ مجوز کار کردن با آنها چگونه است؟
مشکل مهم دیگری که حین کار با نرم افزارها، در حالت متداول آنها وجود دارد، دسترسی کامل آنها به تمام اجزای سیستم و شبکه است و درون یک sandbox (قرنطینه) امنیتی اجرا نمی‌شوند.
مشکل بعدی، به روز رسانی اجزای ثالث سیستم و یا حتی خود سیستم عامل، مانند به روز رسانی OpenSSL نصب شده و پس از آن، از کار افتادن برنامه‌ای خاص است که وابستگی به نگارشی خاص از این کتابخانه را دارد.
کانتینرها در مورد برنامه‌ها هستند و نه مجازی سازی
خوب، تا اینجا دریافتیم که مدیریت توزیع، نصب و استفاده‌ی از برنامه‌ها، کار ساده‌ای نیست. اما این‌ها چه ارتباطی با Docker دارند؟ در بسیاری از اوقات، زمانیکه صحبت از Docker میشود، تصور بسیاری از آن، ارائه‌ی جایگزینی برای ماشین‌های مجازی است. اما ... اینگونه نیست. کانتینرها در مورد نرم افزارها هستند. برای مثال در آینده در مورد ایمیج‌های (Images) کانتینرها بیشتر بحث خواهیم کرد. این ایمیج‌ها در اصل یک بسته‌ی حاوی برنامه‌ها هستند. بنابراین بیشتر شبیه به فایل zip ای است که از یک وب سایت دریافت میکنیم (در قسمت یافتن نرم افزار).
یک کانتینر (Container) چیست؟
برای درک بهتر مواردی که تاکنون بحث شدند و همچنین بررسی مفهوم Containers، ابتدا MonogoDB را به صورت معمول نصب میکنیم. سپس نحوه‌ی نصب آن‌را درون یک Container بررسی خواهیم کرد. البته هدف اصلی در اینجا، بررسی مفهومی این مراحل و مقایسه‌ی آنها با هم هستند و در قسمت‌های بعدی کار نصب و استفاده‌ی از Docker را قدم به قدم بررسی خواهیم کرد.
مراحل نصب محلی MongoDB به صورت متداول:
- ابتدا برای مثال به سایت گوگل مراجعه کرده و mongodb را جستجو میکنیم تا بتوانیم به سایت اصلی و محل دریافت بسته‌ی آن، هدایت شویم.
- پس از ورود به سایت mongodb، در بالای صفحه اصلی آن، لینک به صفحه‌ی دریافت بسته‌ی mongodb را میتوان مشاهده کرد.
- با انتخاب آن، به صفحه‌ی دریافت بسته‌ی mongodb بر اساس سیستم عامل‌های مختلفی هدایت میشویم. برای مثال در ویندوز، بسته‌ی msi آن‌را دریافت میکنیم.
- به نظر میرسد که بسته‌ی نصاب msi آن تمام کارهای لازم برای راه اندازی اولیه‌ی mongodb را انجام می‌دهد. به همین جهت آن‌را اجرا کرده و پس از چندبار انتخاب گزینه‌ی next، نصب آن به پایان میرسد.
- پس از پایان نصب، ابتدا به کنسول service.msc ویندوز مراجعه میکنیم تا مطمئن شویم که سرویس آن، توسط نصاب msi نصب شده‌است یا خیر؟ و ... خیر! این نصاب، سرویس آن‌را نصب نکرده‌است.
- به همین جهت به مستندات نصب آن در سایت mongodb مراجعه میکنیم (لینک Installation instructions در همان صفحه‌ی دریافت بسته‌ی msi وجود دارد). پس از پایان مراحل نصب، عنوان کرده‌است که باید دستور md \data\db را اجرا کنید تا مسیر پیش فرض اطلاعات آن به صورت دستی ایجاد شود. اما ... این مسیر دقیقا به کجا اشاره میکند؟ چون شبیه به مسیرهای ویندوزی نیست.
- در ادامه برای آزمایش، به پوشه‌ی program files ویندوز رفته، monogodb نصب شده را یافته و سپس فایل mongod.exe را از طریق خط فرمان اجرا میکنیم (برنامه‌ی سرور). اگر این کار را انجام دهیم، این پروسه با نمایش خطای یافت نشدن مسیر c:\data\db، بلافاصله خاتمه پیدا میکند. به همین جهت در همین مسیری که در خط فرمان قرار داریم (جائیکه فایل mongod.exe قرار دارد)، دستور md \data\db را اجرا میکنیم. اجرای این دستور در این حالت، همان پوشه‌ی c:\data\db را ایجاد میکند. نکته‌ای که شاید خیلی‌ها با آن آشنایی نداشته باشند.
- اکنون اگر مجددا فایل mongod.exe را اجرا کنیم، اجرای آن موفقیت آمیز خواهد بود و پیام منتظر دریافت اتصالات بودن از طریق پورت 27017 را نمایش می‌دهد.
- مرحله‌ی بعد، اجرای فایل mongo.exe است تا به این دیتابیس سرور در حال اجرا متصل شویم (برنامه‌ی کلاینت). در اینجا برای مثال میتوان دستور show dbs را اجرا کرد تا لیست بانک‌های اطلاعاتی آن‌را نمایش دهد.
مراحل نصب MongoDB به صورت Container توسط Docker:
- ابتدا برای مثال به سایت گوگل مراجعه کرده و اینبار mongodb docker را جستجو میکنیم تا بتوانیم به محل دریافت image آن هدایت شویم. با ورود به آن، در بالای صفحه عنوان شده‌است که official repository است که سبب اطمینان از بسته‌ی ارائه شده‌ی توسط آن میشود. بنابراین در اینجا بجای مراجعه به سایت متکی به خود mongodb، به docker hub برای دریافت آن مراجعه کرده‌ایم. در اینجا با جستجوی یک برنامه، متادیتا و اطلاعات آماری بسیاری را نیز میتوان در مورد برنامه‌های مختلف، مشاهده کرد که در سایت متکی به خود نرم افزارهای مختلف، در دسترس نیستند. همچنین در اینجا اگر بر روی برگه‌ی Tags یک مخزن کلیک کنید، مشاهده میکنید که تمام فایل‌های موجود در آن توسط docker hub از لحاظ مشکلات امنیتی پیشتر اسکن شده‌اند و گزارش آنها قابل مشاهده‌است. علاوه بر این‌ها docker hub به همراه یک docker store برای برنامه‌های غیر رایگان نیز هست و این مورد فرآیند کار با نرم افزارهای تجاری را یک دست میکند.
- مرحله‌ی بعد، دریافت یک کپی از mongodb از docker hub است. اینبار بجای دریافت مستقیم یک فایل zip یا msi، از دستور docker pull mongo استفاده میشود که یک image را در نهایت دریافت میکند. این image، حاوی برنامه‌ی مدنظر و تمام وابستگی‌های آن است.
- پس از دریافت image، مرحله‌ی بعد، اجرای mongodb به همراه آن است. در حالت متداول، ابتدا نرم افزار داخل فایل zip یا msi استخراج شده و سپس بر روی سیستم اجرا میشوند، اما در اینجا مفهوم معادل نصب نرم افزار دریافت شده‌ی از بسته‌ی zip همراه آن، یک container است. یک container دقیقا مانند یک نرم افزار از پیش نصب شده، عمل میکند و معادل اجرای فایل exe مانگو دی بی در اینجا، اجرای container آن است. بنابراین docker، از image دریافت شده، یک container را ایجاد میکند که دقیقا معادل یک نرم افزار از پیش نصب شده، رفتار خواهد کرد.
- پس از دریافت image، جهت اجرای آن به عنوان یک container، برای استفاده از نرم افزاری که دریافت کرده‌ایم، تنها یک دستور است که باید با آن آشنا باشیم: docker run mongo. این دستور را در همان صفحه‌ی docker hub مربوطه نیز میتوانید مشاهده کنید. پس از اجرای این دستور، دقیقا همان خروجی و پیام منتظر دریافت اتصالات بودن از طریق پورت 27017 را مشاهده خواهیم کرد. برای اجرای کلاینت آن نیز دستور docker exec -it 27 mongo را میتوان اجرا کرد. docker exec کار اجرای چندباره‌ی یک نرم افزار نصب شده را انجام می‌دهد.
این فرآیند در مورد تمام containerها یکی است و به این ترتیب به ازای هر نرم افزار مختلف، شاهد روش نصب متفاوتی نخواهیم بود.
- اجرای دستور docker stop نیز سبب خاتمه‌ی تمام این‌ها میشود.
در این تصویر مقایسه‌ای را بین مراحل متداول یافتن، دریافت، نصب و اجرای برنامه‌ها را در دو حالت متداول و همچنین استفاده‌ی از docker، مشاهده میکنید.
همچنین نکته‌ی جالبی که در مورد docker وجود دارد این است که اگر به task manager ویندوز مراجعه کنیم:
تمام پروسه‌هایی که با job id مساوی 172 در اینجا اجرا شده‌اند، متعلق به docker بوده و آنها دقیقا مانند یک پروسه‌ی معمولی سیستم عامل جاری، در کنار سایر پروسه‌های موجود، اجرا میشوند. بنابراین برنامه‌ای که از طریق docker اجرا میشود، هیچ تفاوتی با اجرای متداول آن بر روی سیستم عامل، از طریق روش مراجعه‌ی مستقیم به فایل exe مرتبط و اجرای مستقیم آن ندارد. همانطور که پیشتر نیز عنوان شد، containerها در مورد نرم افزارها هستند و نه مجازی سازی و یک container در حال اجرا، حاوی تعدادی برنامه‌ی در حال اجرای بر روی سیستم عامل جاری، در کنار سایر برنامه‌های آن میباشد.
البته containers به همراه ایزوله سازی‌های بسیاری اجرا میشوند. برای مثال به روز رسانی یک کتابخانه‌ی ثالث بر روی سیستم عامل، سبب از کار افتادن برنامه‌ی اجرای شده‌ی توسط یک container نمیشود.
در قسمت بعد، نحوه‌ی نصب Docker را بر روی ویندوز، بررسی میکنیم.
فرض کنید می‌خواهید یک فایل ویدیویی با قالب m4v را بر روی تلویزیون خود نمایش دهید؛ اما تلویزیون شما تنها از فایل‌های mp4، پشتیبانی میکند. برای رفع این مشکل نیاز به یک نرم افزار تبدیل کننده‌ی فرمت‌های ویدیویی را داریم و یکی از قوی‌ترین‌های آنها، FFmpeg است. اگر به سایت آن مراجعه کنید، لینک دانلود آن به یک فایل tar.bz2 ختم میشود که حاوی سورس آن است! هرچند در قسمتی از آن، فایل‌های نهایی کامپایل شده‌ی مخصوص سیستم عامل‌های مختلف را نیز میتوانید پیدا کنید، اما باز هم با انبوهی از لینک‌ها مواجه خواهید شد که دقیقا مشخص نیست کدام را باید دریافت کرد و آیا نگارش دریافت شده، با سیستم عامل فعلی سازگار است یا خیر.
همانطور که مشاهده میکنید، هنوز هم شروع به کار با نرم افزارهای مختلف برای بسیاری از کاربران، کاری مشکل و طاقت‌فرسا است. در اینجا شاید این سؤال مطرح شود که این موضوع چه ربطی به Docker (Docker) و کانتینرها (Containers) دارد؟ تمام هیاهویی که پیرامون Docker ایجاد شده‌است، در اصل جهت ساده سازی نصب، راه اندازی و تعامل با نرم افزارهای مختلف است.
چالش‌های پیش روی یافتن نرم افزارهای مناسب
این روزها بیشتر نرم افزارهای مورد نیاز خود را از اینترنت تهیه میکنیم. اولین مرحله‌ی آن و اولین چالشی که در اینجا وجود دارد، یافتن نرم افزاری با مشخصات مدنظر است. برای نمونه حتی اگر با FFmpeg آشنا نیز باشید، به سادگی مشخص نیست که برای سیستم عامل و معماری خاص پردازنده‌ی آن، دقیقا کدام نگارش آن‌را از چه آدرسی میتوان دریافت کرد. پس از یافتن نرم افزار و نگارش مدنظر، مرحله‌ی بعد، استخراج محتویات آن از یک فایل zip و یا اجرای برنامه‌ی نصاب آن است و مرحله‌ی آخر، اجرای این برنامه میباشد.
بنابراین اولین چالش، یافتن محلی برای دریافت نرم افزار است:
- این روزها برای بعضی از سکوهای کاری، App Storeهایی وجود دارند که میتوان از آنجا شروع کرد؛ اما چنین قابلیتی برای تمام سکوهای کاری پیش بینی نشده‌است.
- در لینوکس قابلیت دیگری به نام Package manager وجود دارد که کار یافتن و نصب نرم افزارها را ساده میکند؛ اما گاهی از اوقات اطلاعات آن، آنچنان به روز نیست. همچنین اگر بسته‌ای برای توزیع خاصی از لینوکس وجود داشته باشد، الزاما به این معنا نیست که این بسته، قابلیت استفاده‌ی در سایر توزیع‌های لینوکس را نیز به همراه دارد. در ویندوز نیز وضعیت مشخص است! فاقد یک Package manager توکار و استاندارد است. هرچند یک App Store برای آن از طرف مایکروسافت ارائه شده‌است، اما آنچنان محبوبیتی پیدا نکرده‌است.
- و روش متداول دیگری که وجود دارد، مراجعه‌ی مستقیم به سایت اصلی سازنده‌ی نرم افزار است.
- علاوه بر این‌ها داشتن یک سری متادیتا و آمار نیز در مورد نرم افزارها بسیار مفید هستند تا بتوانند در مورد تصمیم به استفاده، یا عدم استفاده‌ی از نرم افزار، راهنمای کاربران باشند؛ مانند میزان محبوبیت، تعداد بار دریافت، تعداد مشکلاتی که کاربران با آن داشته‌اند و آخرین باری که نرم افزار به روز شده‌است. اما با توجه به پراکندگی روش‌های دریافت نرم افزار که ذکر شدند، عموما یک چنین آمارهایی را مشاهده نمی‌کنیم.
- چالش دیگر، مشکل سخت اطمینان کردن به روش‌های مختلف توزیع نرم افزارها است. آیا سایتی که این نرم افزار را ارائه می‌دهد، واقعا مرتبط با نویسنده‌ی اصلی آن است؟ همچنین آیا خود نرم افزار مشکلات امنیتی را به همراه ندارد؟ چه کاری را انجام می‌دهد؟
- مشکل بعدی، در دسترس بودن سایت توزیع کننده‌ی نرم افزار است. آیا زمانیکه به برنامه‌ای نیاز داریم، پهنای باند سایت توزیع کننده‌ی آن تمام نشده‌است و میتوان به آن دسترسی داشت؟
- چالش دیگر، چگونگی پرداخت مبلغی برای دسترسی به نرم افزار است. به نظر تا به اینجا تنها App Storeها موفق شده‌اند روشی یک دست را برای خرید برنامه‌ها و همچنین ارائه‌ی مجوزی برای استفاده‌ی از آنها، ارائه دهند.
چالش‌های پیش روی نصب نرم افزارها
زمانیکه به مرحله‌ی نصب نرم افزار می‌رسیم، هر نرم افزار، روش نصب و تنظیمات آغازین خاص خودش را دارد.
- اولین چالش پس از دریافت نرم افزار، بررسی سازگاری آن با سیستم عامل و پردازنده‌ی فعلی است. شاید این مسایل برای توسعه دهندگان نرم افزارها پیش‌پا افتاده به نظر برسند، اما برای عموم کاربران، چالشی جدی به شما می‌روند.
- پس از مشخص شدن سازگاری یک نرم افزار با سیستم فعلی، قالب ارائه‌ی آن نرم افزار نیز میتوان مشکل‌زا باشد. بعضی از برنامه‌ها صرفا از طریق سورس کد منتشر میشوند. بعضی از آنها توسط یک فایل exe متکی به خود ارائه میشوند و بعضی دیگر به همراه یک فایل exe و تعدادی dll به همراه آنها. گاهی از اوقات این برنامه‌ها نیاز به نصب جداگانه‌ی NET Runtime. و یا Java Runtime را برای اجرا دارند و یا وابستگی آنها صرفا به نگارش خاصی از این کتابخانه‌ها و فریم ورک‌های ثالث است. هرچند اگر برنامه‌ای به همراه بسته‌ی نصاب آن باشد، به احتمال زیاد این وابستگی‌ها را نیز نصب میکند؛ اما تمام برنامه‌ها اینگونه ارائه نمی‌شوند. به علاوه خیلی‌ها علاقه‌ای به کار با برنامه‌های نصاب ندارند و از ایجاد تغییرات بسیاری که آنها در سیستم ایجاد میکنند، خشنود نیستند.
- پس از نصب نرم افزار، مشکل بعدی، نحوه‌ی به روز رسانی آنها است. چگونه باید اینکار انجام شود؟ (تمام مراحل و چالش‌هایی را که تاکنون بررسی کردیم، یکبار دیگر از ابتدا مرور کنید!)
بنابراین همانطور که مشاهده میکنید، نصب، راه اندازی و به روز رسانی نرم افزارها این روزها بسیار پیچیده شده‌اند و بسیاری از کاربران به سادگی از عهده‌ی آنها بر نمی‌آیند.
چالش‌های پیش روی کار با نرم افزارها
مرحله‌ی بعد، نیاز به مستندات کافی برای کار با برنامه است. این مستندات را از کجا میتوان تهیه کرد؟ آخرین باری که به روز شده، چه زمانی بوده‌است؟ بسیاری از اوقات بین مستندات تهیه شده و آخرین نگارش نرم افزار، ناسازگاری وجود دارد و به سختی قابل استفاده‌است. آیا نیاز است برنامه را به PATH اضافه کرد؟ آیا نیاز است به صورت سرویس نصب شود؟ اگر بله، چگونه باید این مراحل را انجام داد؟ مجوز کار کردن با آنها چگونه است؟
مشکل مهم دیگری که حین کار با نرم افزارها، در حالت متداول آنها وجود دارد، دسترسی کامل آنها به تمام اجزای سیستم و شبکه است و درون یک sandbox (قرنطینه) امنیتی اجرا نمی‌شوند.
مشکل بعدی، به روز رسانی اجزای ثالث سیستم و یا حتی خود سیستم عامل، مانند به روز رسانی OpenSSL نصب شده و پس از آن، از کار افتادن برنامه‌ای خاص است که وابستگی به نگارشی خاص از این کتابخانه را دارد.
کانتینرها در مورد برنامه‌ها هستند و نه مجازی سازی
خوب، تا اینجا دریافتیم که مدیریت توزیع، نصب و استفاده‌ی از برنامه‌ها، کار ساده‌ای نیست. اما این‌ها چه ارتباطی با Docker دارند؟ در بسیاری از اوقات، زمانیکه صحبت از Docker میشود، تصور بسیاری از آن، ارائه‌ی جایگزینی برای ماشین‌های مجازی است. اما ... اینگونه نیست. کانتینرها در مورد نرم افزارها هستند. برای مثال در آینده در مورد ایمیج‌های (Images) کانتینرها بیشتر بحث خواهیم کرد. این ایمیج‌ها در اصل یک بسته‌ی حاوی برنامه‌ها هستند. بنابراین بیشتر شبیه به فایل zip ای است که از یک وب سایت دریافت میکنیم (در قسمت یافتن نرم افزار).
یک کانتینر (Container) چیست؟
برای درک بهتر مواردی که تاکنون بحث شدند و همچنین بررسی مفهوم Containers، ابتدا MonogoDB را به صورت معمول نصب میکنیم. سپس نحوه‌ی نصب آن‌را درون یک Container بررسی خواهیم کرد. البته هدف اصلی در اینجا، بررسی مفهومی این مراحل و مقایسه‌ی آنها با هم هستند و در قسمت‌های بعدی کار نصب و استفاده‌ی از Docker را قدم به قدم بررسی خواهیم کرد.
مراحل نصب محلی MongoDB به صورت متداول:
- ابتدا برای مثال به سایت گوگل مراجعه کرده و mongodb را جستجو میکنیم تا بتوانیم به سایت اصلی و محل دریافت بسته‌ی آن، هدایت شویم.
- پس از ورود به سایت mongodb، در بالای صفحه اصلی آن، لینک به صفحه‌ی دریافت بسته‌ی mongodb را میتوان مشاهده کرد.
- با انتخاب آن، به صفحه‌ی دریافت بسته‌ی mongodb بر اساس سیستم عامل‌های مختلفی هدایت میشویم. برای مثال در ویندوز، بسته‌ی msi آن‌را دریافت میکنیم.
- به نظر میرسد که بسته‌ی نصاب msi آن تمام کارهای لازم برای راه اندازی اولیه‌ی mongodb را انجام می‌دهد. به همین جهت آن‌را اجرا کرده و پس از چندبار انتخاب گزینه‌ی next، نصب آن به پایان میرسد.
- پس از پایان نصب، ابتدا به کنسول service.msc ویندوز مراجعه میکنیم تا مطمئن شویم که سرویس آن، توسط نصاب msi نصب شده‌است یا خیر؟ و ... خیر! این نصاب، سرویس آن‌را نصب نکرده‌است.
- به همین جهت به مستندات نصب آن در سایت mongodb مراجعه میکنیم (لینک Installation instructions در همان صفحه‌ی دریافت بسته‌ی msi وجود دارد). پس از پایان مراحل نصب، عنوان کرده‌است که باید دستور md \data\db را اجرا کنید تا مسیر پیش فرض اطلاعات آن به صورت دستی ایجاد شود. اما ... این مسیر دقیقا به کجا اشاره میکند؟ چون شبیه به مسیرهای ویندوزی نیست.
- در ادامه برای آزمایش، به پوشه‌ی program files ویندوز رفته، monogodb نصب شده را یافته و سپس فایل mongod.exe را از طریق خط فرمان اجرا میکنیم (برنامه‌ی سرور). اگر این کار را انجام دهیم، این پروسه با نمایش خطای یافت نشدن مسیر c:\data\db، بلافاصله خاتمه پیدا میکند. به همین جهت در همین مسیری که در خط فرمان قرار داریم (جائیکه فایل mongod.exe قرار دارد)، دستور md \data\db را اجرا میکنیم. اجرای این دستور در این حالت، همان پوشه‌ی c:\data\db را ایجاد میکند. نکته‌ای که شاید خیلی‌ها با آن آشنایی نداشته باشند.
- اکنون اگر مجددا فایل mongod.exe را اجرا کنیم، اجرای آن موفقیت آمیز خواهد بود و پیام منتظر دریافت اتصالات بودن از طریق پورت 27017 را نمایش می‌دهد.
- مرحله‌ی بعد، اجرای فایل mongo.exe است تا به این دیتابیس سرور در حال اجرا متصل شویم (برنامه‌ی کلاینت). در اینجا برای مثال میتوان دستور show dbs را اجرا کرد تا لیست بانک‌های اطلاعاتی آن‌را نمایش دهد.
مراحل نصب MongoDB به صورت Container توسط Docker:
- ابتدا برای مثال به سایت گوگل مراجعه کرده و اینبار mongodb docker را جستجو میکنیم تا بتوانیم به محل دریافت image آن هدایت شویم. با ورود به آن، در بالای صفحه عنوان شده‌است که official repository است که سبب اطمینان از بسته‌ی ارائه شده‌ی توسط آن میشود. بنابراین در اینجا بجای مراجعه به سایت متکی به خود mongodb، به docker hub برای دریافت آن مراجعه کرده‌ایم. در اینجا با جستجوی یک برنامه، متادیتا و اطلاعات آماری بسیاری را نیز میتوان در مورد برنامه‌های مختلف، مشاهده کرد که در سایت متکی به خود نرم افزارهای مختلف، در دسترس نیستند. همچنین در اینجا اگر بر روی برگه‌ی Tags یک مخزن کلیک کنید، مشاهده میکنید که تمام فایل‌های موجود در آن توسط docker hub از لحاظ مشکلات امنیتی پیشتر اسکن شده‌اند و گزارش آنها قابل مشاهده‌است. علاوه بر این‌ها docker hub به همراه یک docker store برای برنامه‌های غیر رایگان نیز هست و این مورد فرآیند کار با نرم افزارهای تجاری را یک دست میکند.
- مرحله‌ی بعد، دریافت یک کپی از mongodb از docker hub است. اینبار بجای دریافت مستقیم یک فایل zip یا msi، از دستور docker pull mongo استفاده میشود که یک image را در نهایت دریافت میکند. این image، حاوی برنامه‌ی مدنظر و تمام وابستگی‌های آن است.
- پس از دریافت image، مرحله‌ی بعد، اجرای mongodb به همراه آن است. در حالت متداول، ابتدا نرم افزار داخل فایل zip یا msi استخراج شده و سپس بر روی سیستم اجرا میشوند، اما در اینجا مفهوم معادل نصب نرم افزار دریافت شده‌ی از بسته‌ی zip همراه آن، یک container است. یک container دقیقا مانند یک نرم افزار از پیش نصب شده، عمل میکند و معادل اجرای فایل exe مانگو دی بی در اینجا، اجرای container آن است. بنابراین docker، از image دریافت شده، یک container را ایجاد میکند که دقیقا معادل یک نرم افزار از پیش نصب شده، رفتار خواهد کرد.
- پس از دریافت image، جهت اجرای آن به عنوان یک container، برای استفاده از نرم افزاری که دریافت کرده‌ایم، تنها یک دستور است که باید با آن آشنا باشیم: docker run mongo. این دستور را در همان صفحه‌ی docker hub مربوطه نیز میتوانید مشاهده کنید. پس از اجرای این دستور، دقیقا همان خروجی و پیام منتظر دریافت اتصالات بودن از طریق پورت 27017 را مشاهده خواهیم کرد. برای اجرای کلاینت آن نیز دستور docker exec -it 27 mongo را میتوان اجرا کرد. docker exec کار اجرای چندباره‌ی یک نرم افزار نصب شده را انجام می‌دهد.
این فرآیند در مورد تمام containerها یکی است و به این ترتیب به ازای هر نرم افزار مختلف، شاهد روش نصب متفاوتی نخواهیم بود.
- اجرای دستور docker stop نیز سبب خاتمه‌ی تمام این‌ها میشود.
در این تصویر مقایسه‌ای را بین مراحل متداول یافتن، دریافت، نصب و اجرای برنامه‌ها را در دو حالت متداول و همچنین استفاده‌ی از docker، مشاهده میکنید.
همچنین نکته‌ی جالبی که در مورد docker وجود دارد این است که اگر به task manager ویندوز مراجعه کنیم:
تمام پروسه‌هایی که با job id مساوی 172 در اینجا اجرا شده‌اند، متعلق به docker بوده و آنها دقیقا مانند یک پروسه‌ی معمولی سیستم عامل جاری، در کنار سایر پروسه‌های موجود، اجرا میشوند. بنابراین برنامه‌ای که از طریق docker اجرا میشود، هیچ تفاوتی با اجرای متداول آن بر روی سیستم عامل، از طریق روش مراجعه‌ی مستقیم به فایل exe مرتبط و اجرای مستقیم آن ندارد. همانطور که پیشتر نیز عنوان شد، containerها در مورد نرم افزارها هستند و نه مجازی سازی و یک container در حال اجرا، حاوی تعدادی برنامه‌ی در حال اجرای بر روی سیستم عامل جاری، در کنار سایر برنامه‌های آن میباشد.
البته containers به همراه ایزوله سازی‌های بسیاری اجرا میشوند. برای مثال به روز رسانی یک کتابخانه‌ی ثالث بر روی سیستم عامل، سبب از کار افتادن برنامه‌ی اجرای شده‌ی توسط یک container نمیشود.
در قسمت بعد، نحوه‌ی نصب Docker را بر روی ویندوز، بررسی میکنیم.
تا قبل از اضافه شدن دیتاتایپ JSON به صورت توکار در MySQL، داده‌های JSON را تنها میتوانستیم با فرمت رشته‌ای، درون دیتابیس ذخیره کنیم:
اما مشکل اینجاست که هیچ نوع اعتبارسنجی بر روی این دیتا صورت نخواهد گرفت؛ هیچ روشی برای مطمئن شدن از اینکه تگ‌ها به درستی استفاده شده‌اند، وجود ندارد و همچنین امکان جستجو را سخت خواهد کرد؛ زیرا مجبور خواهیم بود از Regular Expressions برای جستجوی درون متن‌های ذخیره شده استفاده کنیم:
همانطور که مشاهده میکنید، تابع JSON_EXTRACT یک آرگومان دومی را نیز دریافت میکند که توسط آن میتوانیم path موردنظر را وارد کنیم و همانطور که عنوان شد، از $ برای دسترسی به سند جاری استفاده میکنیم. سپس در ادامه نام پراپرتی‌ای را که میخواهیم استخراج کنیم، تعیین کرده‌ایم. در اینجا چون ساختار ذخیره شده، به صورت شیء میباشد، به صورت مستقیم از $ و بعد از آن نقطه و سپس نام پراپرتی استفاده کرده‌ایم. میتوانیم عمق پیمایش را نیز بیشتر کنیم. به عنوان مثال برای دسترسی به المنت دوم از آرایه tag درون دیتا خواهیم داشت:
آرگومان اول این تابع، داکیومنتی است که میخواهیم جستجو کنیم. برای آرگومان دوم، یکی از دو مقدار one یا all را میتوانیم تنظیم کنیم. در ادامه لیستی از pathهایی را که میخواهیم جستجو کنیم، وارد کرده‌ایم. در حالت one، اگر تنها یکی از pathها درون داکیومنت JSON وجود داشته باشند، خروجی ۱ خواهد بود. اگر one را به all تنظیم کنیم، یعنی باید تمامی pathها، درون داکیومنت وجود داشته باشند تا خروجی ۱ شود؛ در غیراینصورت خروجی ۰ خواهد بود.
CREATE TABLE tableName (
jsonData CHAR(250) -- or VARCHAR, TEXT, BLOB
);
INSERT INTO tableName VALUES (
'{ "name": "User1", "age": 41}'
);
SELECT * FROM tableName;
{ "name": "User1", "age": 41} SELECT * FROM tableName WHERE jsonData REGEXP 'User1';
از نسخه MySQL 5.7.8 به بعد، میتوانیم از نوع داده JSON برای ذخیره‌سازی محتوای JSON، استفاده کنیم. از این دیتاتایپ برای ذخیره‌سازی یک JSON document معتبر میتوان استفاده کرد:
CREATE TABLE tableName (
jsonData JSON
);
INSERT INTO tableName VALUES (
'{ "name": "User1", "age": 41, "name": "User2"}'
);
SELECT * FROM tableName;
{"age": 41, "name": "User2"} همانطور که مشاهده میکنید MySQL به صورت اتوماتیک یکسری نرمال‌سازی را روی دیتا اعمال کرده است:
- ابتدا بررسی خواهد شد که سند JSON معتبر باشد؛ در غیر اینصورت ذخیره‌سازی با مشکل مواجه خواهد شد.
- از فیلدهایی که کلید تکراری دارند، صرفنظر خواهند شد. در مثال بالا دوبار فیلد name را مقداردهی کرده‌ایم. در اینجالت key/value دوم لحاظ شده‌است. البته میبایستی اصل first key wins لحاظ میشد، اما این مورد به عنوان یک باگ گزارش شده‌است و در نسخه‌های 8 به بعد رفع شده‌است (https://forums.mysql.com/read.php?3,660500,660500 - https://bugs.mysql.com/bug.php?id=86866).
- فاصله‌های اضافی بین کلیدها حذف شده‌اند.
- برای جستجوی بهتر، کلیدهای آبجکت JSON به صورت مرتب شده ذخیره شده‌اند.
جستجو درون JSON Document
یک سند JSON، از یکسری کلیدها به همراه مقادیرشان تشکیل شده‌است. همچنین مقادیر میتوانند شامل اشیاء یا آرایه‌هایی به صورت تودرتو باشند. بنابراین به یک path جهت استخراج مقادیر نیاز خواهیم داشت. برای نوشتن یک path باید scope آن را تعیین کنیم که در توابع MySQL این scope به صورت پیش‌فرض، سند جاری میباشد که توسط علامت $ مشخص میشود.
فرض کنید ساختار زیر را درون دیتابیس ذخیره کرده‌ایم:
{
"id": "1",
"sku": "asdf123",
"name": "Lorem ipsum jacket",
"price": 12.45,
"discount": 10,
"offerEnd": "October 5, 2020 12:11:00",
"new": false,
"rating": 4,
"saleCount": 54,
"category": ["fashion", "men"],
"tag": ["fashion", "men", "jacket", "full sleeve"],
"variation": [
{
"color": "white",
"image": "/assets/img/product/fashion/1.jpg",
"size": [
{
"name": "x",
"stock": 3
},
{
"name": "m",
"stock": 2
},
{
"name": "xl",
"stock": 5
}
]
},
{
"color": "black",
"image": "/assets/img/product/fashion/8.jpg",
"size": [
{
"name": "x",
"stock": 4
},
{
"name": "m",
"stock": 7
},
{
"name": "xl",
"stock": 9
},
{
"name": "xxl",
"stock": 1
}
]
},
{
"color": "brown",
"image": "/assets/img/product/fashion/3.jpg",
"size": [
{
"name": "x",
"stock": 1
},
{
"name": "m",
"stock": 2
},
{
"name": "xl",
"stock": 4
},
{
"name": "xxl",
"stock": 0
}
]
}
],
"image": [
"/assets/img/product/fashion/1.jpg",
"/assets/img/product/fashion/3.jpg",
"/assets/img/product/fashion/6.jpg",
"/assets/img/product/fashion/8.jpg",
"/assets/img/product/fashion/9.jpg"
],
"description": {
"shortDescription": "Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur.",
"fullDescription": "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur? Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"
}
} برای دریافت دسته‌بندی‌های هر ردیف میتوانیم از تابع JSON_EXTRACT استفاده کنیم:
SELECT
JSON_PRETTY(
JSON_EXTRACT(data, "$.category")
)
FROM
experiments.productMetadata;
/*
[
"fashion",
"men"
]
[
"fashion",
"women"
]
[
"fashion",
"men"
]
*/ JSON_EXTRACT(data, "$.tag[1]") JSON_EXTRACT(data, "$.description.shortDescription")
همچنین اگر کلید مقداری را که میخواهیم جستجو کنیم، بدانیم اما از کلید والد آن اطلاع نداشته باشیم، میتوانیم از * استفاده کنیم:
SELECT JSON_EXTRACT(data, "$.*.shortDescription") FROM experiments.productMetadata;
JSON_KEYS
از این تابع جهت دریافت کلیدهای top level یک شیء JSON استفاده میشود:
SELECT JSON_KEYS(data) FROM experiments.productMetadata; -- ["id", "new", "sku", "tag", "name", "image", "price", "rating", "category", "discount", "offerEnd", "saleCount", "variation", "description"] -- ["id", "new", "sku", "tag", "name", "image", "price", "rating", "category", "discount", "saleCount", "variation", "description"]
همچنین میتوانیم path را نیز به عنوان آرگومان دوم آن تعیین کنیم:
SELECT JSON_KEYS(data, "$.description") FROM experiments.productMetadata; -- ["fullDescription", "shortDescription"] -- ["fullDescription", "shortDescription"]
JSON_CONTAINS
از این تابع برای جستجو استفاده خواهیم کرد و همانطور که از نام آن پیداست، در صورت وجود مقدار مورد جستجو، خروجی ۱ خواهد بود:
SELECT
JSON_CONTAINS(data, "10", "$.discount")
FROM
experiments.productMetadata;
-- 1
-- 0 JSON_CONTAINS_PATH
توسط این تابع میتوانیم بررسی کنیم که یک path یا یک یکسری path خاص درون JSON document وجود دارند یا خیر:
SELECT JSON_CONTAINS_PATH(data, "one", "$.description", "$.address", "$.website") FROM experiments.productMetadata;
JSON_SEARCH
توسط این تابع میتوانیم position مقدار مورد جستجو را درون داکیومنت JSON پیدا کنیم:
SELECT
JSON_SEARCH(data, 'one', 'fashion')
FROM
experiments.productMetadata;
-- "$.tag[0]"
-- "$.tag[0]" 
استفاده یا عدم استفاده از یک تکنولوژی یا ابزار خاص، به پارامترهای مختلفی از جمله ابعاد پروژه، مهارت و دانش اعضای تیم، ماهیت پروژه، پلتفرم اجرا، بودجه‌ی پروژه، مهلت تکمیل پروژه و تعداد نفرات تیم بستگی دارد. بنابراین واضح است پیچیدن یک نسخه‌ی خاص، برای همه‌ی سناریو‌ها امکان پذیر نیست؛ اما شرایطی وجود دارد که استفاده یا عدم استفاده از این ابزارهای تکنولوژیک منطقی‌تر مینمایند.
Stored Procedure (که از این به بعد برای ایجاز، SP نوشته خواهد شد) هم از قاعده فوق مستثنی نیست و در صورت انتخاب صحیح میتواند به ارائه‌ی محصول نهایی با کیفیت‌تری در زمان کوتاه‌تری کمک کند و در صورت انتخاب ناآگاهانه ممکن است باعث شکست یک پروژه (بخصوص در بلند مدت) شود.
تاریخچه
SQL توسط شرکت IBM در اوایل دهه 70 میلادی ایجاد شد. با اوج گرفتن زبان‌های رویه‌ای، SQL هم چندان از این قافله عقب نماند که منجر به پذیرش SP به عنوان یک استاندارد، در دهه 90 میلادی و پیاده سازی تدریجی آن توسط غول‌های سازنده دیتابیس شد (رجوع فرمایید به ^ و ^). این فاصله 20 ساله باعث غنی‌تر شدن SQL شد و وجود SP - به معنی انتقال مدل برنامه نویسی رویه‌ای به SQL - بخشی از مشکلات قبلی کار با کوئری‌های پشت سر هم و خام را حل کرد. از سال 2000 میلادی به بعد، ORMهای قدرتمندی از جمله Hibernate و پیاده سازی‌های مختلفی از Active Record و Entity Framework متولد شدند. بنابر این تقدم و تاخّرهای زمانی، بدیهی است اغلب مزایای SP نسبت به Raw SQL Query و اغلب معایب آن نسبت به ORMها باشد.
بنظر میرسد برای پاسخ به سوال اصلی این مطلب، ناگزیر به مقایسه SP با رقبای دیرینه‌اش هستیم. با برشمردن معایب و مزایای SP میتوان به نتیجه‌ی منطقی‌تری رسید. البته باید در نظر داشت صرف استفاده از SP به معنای بهره‌مند شدن از مزایای آن و صرف استفاده نکردن از آن هم بهره‌مندی از رقبای آن نیست. چگونگی استفاده یک ابزار، مهمتر از خود ابزار است.
معایب SP
- دستورات Alter Table ، Add Column و Drop Column به این سادگی‌ها هم نیستند؛ ممکن است به یکی از جداول دیتابیس دو ستون اضافه یا از آن حذف شوند. مجبوریم تمامی SPها را بخصوص Insert و Update متناظر با جدول را تغییر دهیم که این تغییرات ممکن است بصورت زنجیره‌وار به سایر SPها هم سرایت کند. حال شرایطی را در نظر بگیرید که تعداد SPهای شما به چند ده و یا حتی به چند صد عدد و بیشتر، رسیده باشد که این به معنی زحمت بیشتر و تغییرات پر هزینه‌تر است.
- احتمال کند شدن ماشین سرویس دهنده در اثر اجرای تعداد
زیادی SP ؛ چناچه بخش زیادی از منطق برنامه از طریق SP اجرا شود، سرور دیتابیس موظف به اجرای آنهاست. اما در صورتیکه منطق،
در کد برنامه قرار داشته باشد، امکان توزیع آن بر روی سرور‌های مجزا و یا حتی ماشین
کلاینت وجود خواهد داشت. امروزه اکثر کلاینت‌ها به دیتابیس‌های سبک و سریعی مجهز شده‌اند. بنابراین در صورت امکان چرا بار پردازشی را به عهده آنها نگذاریم؟!
- یکپارچگی کمتر؛ تقریبا همه اپلیکیشن‌ها نیازمند
ارتباط با سایر سیستم‌ها هستند. اگر بخش‌های زیادی از منطق برنامه درون SP مخفی شده باشند، این نقطه تلاقی بین سیستمی، احتمالا
درون خود دیتابیس قرار میگیرد و این به معنی ایجاد SP های بیشتر، افزودن
پارامترهای بیشتر، توسعه SPهای قبلی و بطور
خلاصه اعمال تغییرات بیشتر، که منتج به قابلیت نگهداری کمترخواهد شد.
- انعطاف پذیری کمتر؛ در یک شرایط ایده آل، عملکرد اپلیکیشن، مستقل از دیتابیس است. اگر نیاز به تغییر دیتابیس، مثلا از اوراکل به Microsoft SQL Server وجود داشته باشد، نیاز به بازنویسی و انتقال فانکشن‌ها و SP ها محتمل است و از آنجائیکه که با وجود استانداردها، دیتابیس‌های مختلف، معمولا در Syntax دستورات، تفاوت‌های فاحشی دارند، هر چه کد بیشتری در SP ها باشد، نیاز به انتقال و تبدیل بیشتری وجود دارد.
- عدم وجود بازخورد مناسب؛ بسیاری از اوقات در صورت بروز اشکالی در حین اجرای یک SP، فقط با یک متن ساده بصورت Table has no rows و یا error مواجه میشویم. چنین خطاهایی هنگام دیباگ اصلا خوشایند نیستند. MS SQL در این بین بازخورد‌های مناسبی را ارائه میکند. اگر تجربه کار با سایر دیتابیس‌ها را داشته باشید، اهمیت بازخورد‌های مناسب، ملموس‌تر خواهد بود.
- کد نویسی سخت‌تر؛ نوشتن کد SQL معمولا در همان IDE اپلیکیشن انجام نمیشود. جابجایی مداوم بین دو IDE ، دیباگ و کد نویسی از طریق دو اینترفیس مجزا، اصلا ایده‌ال نیست.
- SP منطق را بیش از حد پنهان میکند؛ حتی با دانستن نام صحیح یک SP، باز هم تصویری از پارامترهای ارسالی به آن و نتیجه برگشتی نخواهیم داشت. نمیدانیم نتیجه حاصل از اجرای SP ما مقداری را برمیگرداند یا خیر؟ در صورت وجود برگشتی، یک Cursor است یا یک مقدار؟ اگر Cursor است شامل چه ستون‌هایی است؟
- SP نمیتواند یک شیء را به عنوان آرگومان بپذیرد؛ بنابراین احتمال کثیف شدن کد به مرور افزایش پیدا میکند و بدتراز آن، در صورت ارسال اشتباه یک پارامتر، یا عدم تطابق تعداد پارامتر‌ها، مجبور به بررسی تمام آنها بصورت دستی هستیم. برای مثال دو قطعه کد زیر را با هم مقایسه کنید:
INSERT INTO User_Table(Id,Username,Password,FirstName,SureName,PhoneNumber,x,Email) VALUES (1,'VahidN','123456','Vahid','Nasiri','09120000000','vahid_xxx@example.com')
و معادل آن در یک ORM فرضی:
public void Insert(User user)
{
_users.Insert(user);
db.Save();
} به‌وضوح قطعه کد sql، قبل از خوب یا بد بودن، زشت است. همچنین پارامتر x آن که فرضاً به تازگی اضافه شده، مقداری را دریافت نکرده و باعث بروز خطا خواهد شد.
- نبود Query Chaining؛ یکی از ویژگی‌های جذاب ORMهای امروزی، امکان تشکیل یک کوئری با قابلیت خوانایی بالا و افزودن شرط‌های بیشتر از طریق الگوی builder است. قطعه کد زیر یک SP برای جستجوی داینامیک نام و نام خانوادگی در یک جدول فرضی به اسم Users است:
public ICollection<User> GetUsers(string firstName,string lastName,Func<User, bool> orderBy)
{
var query = _users.where(u => u.LastName.StartsWith(lastName));
query = query.where(u => u.FirstName.StartsWith(firstName));
query = query.OrderBy(orderBy);
return query.ToList();
} در مقایسه با معادل SP آن:
CREATE PROCEDURE DynamicWhere
@LastName varchar(50) = null,
@FirstName varchar(50) = null,
@Orderby varchar(50) = null
AS
BEGIN
DECLARE @where nvarchar(max)
SELECT @where = '1 = 1'
IF @LastName IS NOT NULL
SELECT @Where = @Where + " AND A.LastName LIKE @LastName + '%'"
IF @FirstName IS NOT NULL
SELECT @Where = @Where + " AND A.FirstName LIKE @FirstName + '%'"
DECLARE @orderBySql nvarchar(max)
SELECT @orderBySql = CASE
WHEN @OrderBy = "LastName" THEN "A.LastName"
ELSE @OrderBy = "FirstName" THEN "A.FirstName"
END
DECLARE @sql nvarchar(max)
SELECT @sql = "
SELECT A.Id , A.AccountNoId, A.LastName, A.FirstName, A.PostingDt,
A.BillingAmount
FROM Users
WHERE " + @where + "
ORDER BY " + @orderBySql
exec sp_executesql @sql, N'@LastName varchar(50), @FirstName varchar(50)
@LastName, @FirstName
END حاجت به گفتن نیست که قطعه کد اول چقدر خواناتر، انعطاف پذیرتر، خلاصه‌تر و قابل نگهداری‌تر است.
- نداشتن امکانات زبان‌های مدرن؛ زبان‌ها و IDEهای مدرن، امکانات قابل توجهی را برای نگهداری بهتر، انعطاف پذیری بیشتر، مقیاس پذیری بالاتر، تست پذیری دقیقتر و... ارائه میکنند. به عنوان مثال:
- شیءگرایی و امکانات آن که در SP موجود نیست و در مورد قبلی معایب، به آن مختصرا اشاره شد. در نظر بگیرید اگر SQL زبانی شیء گرا بود و مجهز به ارث بری و کپسوله سازی بود، چقدر قابلیت نگهداری آن بالاتر میرفت و حجم کدهای نوشته شده میتوانست کمتر باشند.
- نداشتن Lazy Loading که باعث مصرف زیاد حافظه میشود.
- نداشتن intellisense حین فراخوانی‌ها.
- نداشتن Navigation Property که باعث join نویسی‌های زیاد خواهد شد.
- SQL در مقایسه با یک زبان مدرن ناقص بنظر میرسد و این نوشتن کد آن را سخت‌تر میکند.
- نداشتن امکان تغییر منطقی نام جداول و ستون ها
- مدیریت تراکنش‌ها بصورت دستی، حال آنکه با الگوی Unit Of Work این مشکل در یک ORM قدرتمند مثل EF حل شده است.
- زمان بر بودن نوشتن SP؛ گاهی نوشتن یک تابع در یک ORM یا بعضا نوشتن یک کوئری SQL کوتاه در یک رشته متنی، ساده‌تر از نوشتن کد SP است. آیا برای هر وظیفه کوچک در دیتابیس، نوشتن یک SP ضروری است؟
مزایای SP :
- کمتر کردن Round Trips در شبکه و متعاقبا کاهش ترافیک شبکه؛ اگر از یک فراخوانی استفاده کنیم، کاهش Round Tripها تاثیر چندانی نخواهد داشت. همچنین ارسال یک کوئری کامل، نسبت به ارسال فقط اسم SP و پارامترهای آن، پهنای باند بیشتری اِشغال میکند. البته در یک شبکه با سرعت قابل قبول، بعید است این دو مزیت محسوس باشند؛ اما به هر حال برای موارد خاص، دو مزیت محسوب میشوند. نکته دیگر آنکه بدلیل Pre-Compiled بودن SPها و همچنین کَش شدن Execution Plan آنها، اندکی با سرعت بالاتری اجرا میشوند.
- امکان چک کردن سینتکس قبل از اجرای آن؛ در مقایسه با Raw Query مزیت محسوب میشود.
- امکان به اشتراک گذاری کد؛ برای پروژه‌هایی که چندین اپلیکیشن با چندین زبان برنامه نویسی مختلف در حال تهیه هستند و نیازمند دسترسی مستقیم به داده‌ها با سرعت به نسبت بالاتری هستند، SP میتواند یک راه حل ایده آل محسوب شود. بجای پیاده سازی منطق برنامه در هر اپلیکیشن بصورت جداگانه و زحمت کدنویسی هرکدام، میتوان از SP استفاده کرد. هرچند امروزه معمولا برای حل این مشکل، API های مشترک معماری Restful ارجحیت دارد.
- کمک به ایجاد یک پَک؛ در یک زیر سیستم با نیازمندی مشخص که اعمال تغییرات در آن محتمل نمیباشد نیز SP میتواند یک گزینه مناسب به حساب آید. مثلا یک سیستم Membership را در نظر بگیرید که در پروژه‌های مختلف شما مورد استفاده قرار خواهد گرفت. برای مثال میشود یک سیستم Membership سفارشی را با امکان Hash پسورد و رمز کردن داده‌های حساس، به کمک SP و Function های مناسب فراهم کرد و در واقع بین Application Login و Data Logic تمایز قائل شد. شخصا معماری Restful را به این روش هم ترجیح میدهم.
- بهرمند شدن از امکانات بومی SQL ؛ به عنوان نمونه برای ترانهاده کردن خروجی یک کوئری میتوان از فانکشن Pivot استفاده کرد. یا فانکشن‌های تحلیلی Lead و Lag (لینک مستندات اوراکل این دو فانکشن به ترتیب در ^ و ^ ) که بنظر نمیرسد هنوز معادل مستقیمی درORM ها داشته باشند.
- تسلط و کنترل بیشتر و دقیقتر بر کوئری نهایی؛ گفته میشود SP و عبارات SQL در دیتابیس، حکم assembly را در سایر زبان‌ها دارند. بنابراین با SP میتوان عبارات SQL و نحوه اجرای آن را در دیتابیس، بطور کامل تحت فرمان داشت. این در حالی است که هر یک از ORMها دستورات زبان برنامه نویسی مبداء را به یک عبارت SQL ترجمه میکنند که این عبارت چندان تحت کنترل برنامه نویس نیست و بیشتر به مدل کاری ORM بستگی دارد.
- امکان join بین دو یا چند دیتابیس مجزا؛ حال آنکه امکان join بین دو Context در ORM ها وجود ندارد. بعلاوه اگر دو دیتابیس مدنظر ما روی دو سرور مجزا باشند، با SP و کانفیگ Linked Server کماکان میشود کوئری join دار نوشت.
- برای عملیات‌های Batch مناسب‌تر است؛ در مقام مقایسه با ORM ها که با تکنیک‌های مختلفی سعی در افزایش سرعت عملیات Batch، بخصوص Insert و Update را دارند، SP با سرعت قابل قبول‌تری اجرا میشود.
- عدم نیاز به یادگیری سینتکس و ابزاری جدید؛ موارد
بسیاری وجود دارند که فرصت یادگیری تکنولوژی جدیدی مثل یک ORM و یا SQL Bulk و حتی کتابخانه‌های ثالث مبتنی بر این ابزارها وجود ندارند و ممکن است مجبور شوید برای باقی ماندن در بازار رقابتی، از
دانسته‌های قبلی خود استفاده کنید .
- تخصصی‌تر کردن وظایف؛ برنامه نویس‌های دیتابیس به صورت تخصصی اقدام به تحلیل روابط و ایندکس‌ها میکنند، دیتابیس را ایجاد و نرمال سازی مینمایند، SP های متناسب را میسازند و به بهترین شکل Optimize و در آخر تست میکنند.
- امنیت به نسبت بالاتر؛ میتوان مجوز اجرای SP را به یک کاربر اعطا کرد، بدون آنکه مجوز دسترسی به جداول مورد استفاده در آن SP را داد. همچنین نسبت به کوئری‌های پارامتری نشده، SQL ارجیحت دارند چون احتمال آسیب پذیری در مقابل SQL Injection را کمتر میکنند.
نتیجه‌گیری
اگرچه SP ها برای پردازش داده‌ها آنقدر هم که در وبلاگ‌ها میخوانیم بد نیستند، اما سوء استفاده از آن، مشکلات عدیده‌ای را ایجاد خواهد کرد. با توجه به روند تغییرات تکنولوژی‌های دسترسی به داده‌ها و معماری‌های مدرن بنظر میرسد SP در بهترین حالت، ابزار مناسبی برای انجام عملیات CRUD است و نه بیشتر؛ مگر در مواردی خاص که به تشخیص شما نیاز به استفاده بیشتر از آن وجود داشته باشد.
لطفا پروایدر MySQL مخصوص ADO.NET را که در وب سایت رسمی MySQL قابل دریافت نیست،در صورتی که براتون مقدور بود (حجم و ...) در اینجا بارگذاری کنید
با تشکر
با تشکر