Object-relational Mappers

محمد صداقتیپایتون

Object-relational Mappers یا به اختصار (ORMs) یک کتابخانه کد است که انتقال داده‌های ذخیره شده در جداول پایگاه داده‌های رابطه‌ای را به Objectهایی که بیشتر در کدهای برنامه‌نویسی استفاده می‌شوند، به‌طور خودکار انجام می‌دهد.

شاید این توضیح در ابتدا کمی پیچیده به نظر برسد اما به زبان ساده نوشتن کدهای دیتابیس به زبان برنامه‌نویسی دیگری است.

 

چرا از ORMها استفاده می‌کنیم؟

ORMs  یک انتزاع سطح بالا بر روی پایگاه داده‌های رابطه‌ای فراهم می‌کنند که به یک توسعه‌دهنده این امکان را می‌دهد تا به جای نوشتن دستورات SQL ، کدها را به زبان  Python بنویسد تا داده‌ها و ساختارهای پایگاه داده خود را ایجاد، خواندن، به‌روزرسانی و حذف کند. توسعه‌دهندگان می‌توانند از زبان برنامه‌نویسی که با آن راحت هستند برای کار با پایگاه داده استفاده کنند، به جای نوشتن دستورات SQL یا رویه‌های ذخیره‌شده.

برای مثال، بدون ORM، یک توسعه‌دهنده باید دستور SQL زیر را برای بازیابی هر سطر در جدول USERS که در آن ستون zip_code برابر با ۹۴۱۰۷ است، بنویسد:

SELECT * FROM USERS WHERE zip_code=94107

دستور معادل در Django ORM به جای آن، به صورت کد Python زیر خواهد بود:

 obtain everyone in the 94107 zip code and assign to users variable#

users = Users.objects.filter(zip_code=94107)

 

قابلیت نوشتن کد Python به جای SQL می‌تواند سرعت توسعه برنامه‌های وب را افزایش دهد، به‌ویژه در ابتدای یک پروژه. افزایش سرعت بالقوه توسعه از این ناشی می‌شود که نیازی به تغییر از کد Python به نوشتن دستورات SQL در پارادایم اعلامی نیست. در حالی که برخی از توسعه‌دهندگان نرم‌افزار ممکن است مشکلی با جابجایی بین زبان‌ها نداشته باشند، معمولاً راحت‌تر است که یک پروتوتایپ را با استفاده از یک زبان برنامه‌نویسی واحد بسازید یا یک برنامه وب را شروع کنید.

ORMها همچنین به طور نظری این امکان را می‌دهند که یک برنامه را بین پایگاه داده‌های مختلف رابطه‌ای جابجا کنید. برای مثال، یک توسعه‌دهنده می‌تواند از SQLite برای توسعه محلی و از MySQL در تولید استفاده کند. یک برنامه تولیدی می‌تواند به راحتی از MySQL به PostgreSQL با حداقل تغییرات در کد منتقل شود.

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

 

آیا باید از یک ORM برای برنامه وب خود استفاده کنم؟

کتابخانه‌های ORM در پایتون برای دسترسی به پایگاه داده‌های رابطه‌ای ضروری نیستند. در واقع، دسترسی سطح پایین معمولاً توسط کتابخانه دیگری به نام کانکتور پایگاه داده، مانند psycopg (برای PostgreSQL) یا MySQL-python (برای MySQL) فراهم می‌شود. به جدول زیر نگاهی بیندازید که نشان می‌دهد چگونه ORMها می‌توانند با فریم‌ورک‌های مختلف وب، کانکتورها و پایگاه داده‌های رابطه‌ای کار کنند.

نمونه‌هایی از نحوه کارکرد ORMهای مختلف پایتون با کانکتورها و بک‌اندهای مختلف.

 

 

جدول بالا نشان می‌دهد که به عنوان مثال، SQLAlchemy  می‌تواند با فریم‌ورک‌های مختلف وب و کانکتورهای پایگاه داده کار کند. توسعه‌دهندگان همچنین می‌توانند از ORM ها بدون استفاده از یک فریم‌ورک وب استفاده کنند، مانند زمانی که یک ابزار تحلیل داده یا یک اسکریپت دسته‌ای بدون رابط کاربری ایجاد می‌کنند.

معایب استفاده از ORM چیست؟

ORMها معایب متعددی دارند که شامل:

  • ناسازگاری و ناهماهنگی
  • کاهش عملکرد احتمالی
  • انتقال پیچیدگی از پایگاه داده به کد برنامه

ناکارآمدی و ناسازگاری

عبارت “ناکارآمدی ” معمولاً در ارتباط با ORM ها استفاده می‌شود. این عبارت یک اصطلاح عمومی برای دشواری‌هایی است که هنگام جابجایی داده‌ها بین جداول رابطه‌ای و ابجکت‌های برنامه‌نویسی رخ می‌دهد. نکته این است که روشی که یک توسعه‌دهنده از آبجکت استفاده می‌کند با نحوه ذخیره‌سازی و پیوستن داده‌ها در جداول رابطه‌ای تفاوت دارد.

این مقاله در مورد ناسازگاری ORM توضیح کاملی می‌دهد تا این مفهوم را به صورت کلی شفاف گردد و نمودارهایی برای نشان دادن علت بروز مشکل ارائه می‌دهد.

کاهش عملکرد احتمالی

یکی از نگرانی‌هایی که با هر توزیع سطح بالاتر یا فریم‌ورک همراه است، کاهش عملکرد احتمالی است. در ORMها، کاهش عملکرد ناشی از ترجمه کد برنامه به یک دستور SQL معادل است که ممکن است به درستی بهینه نشده باشد.

ORMها همچنین اغلب برای امتحان کردن آسان هستند اما تسلط بر آن‌ها دشوار است. به عنوان مثال، یک مبتدی که از Django  استفاده می‌کند ممکن است از تابع select_related() و نحوه بهبود عملکرد روابط کلید خارجی برخی از کوئری‌ها بی‌خبر باشد. ده‌ها نکته و ترفند برای بهبود عملکرد در هر ORM وجود دارد. ممکن است صرف زمان برای یادگیری این ویژگی‌ها بهتر از صرف وقت برای یادگیری SQL و نوشتن رویه‌های ذخیره‌شده باشد.

در این بخش، از عبارات “ممکن است” و “احتمال” زیاد استفاده شده است. در پروژه‌های بزرگ، ORMها برای حدود ۸۰-۹۰٪ از موارد استفاده خوب هستند اما در ۱۰-۲۰٪ از تعاملات پایگاه داده یک پروژه، می‌توان با نوشتن دستورات SQL بهینه‌شده توسط یک مدیر پایگاه داده باتجربه، بهبودهای عملکردی بزرگی ایجاد کرد.

انتقال پیچیدگی از پایگاه داده به کد برنامه

کدی که با داده‌های یک برنامه کار می‌کند باید جایی وجود داشته باشد. قبل از اینکه ORM ها رایج شوند، از رویه‌های ذخیره‌شده پایگاه داده برای انکپسوله کردن منطق پایگاه داده استفاده می‌شد. با استفاده از ORM ، کد تغییرداده شده داده‌ها به جای آنکه در منطق پایگاه داده باشد، در کد Python برنامه قرار می‌گیرد. اضافه کردن منطق کدهای تغییر داده شده داده‌ها به کد برنامه معمولاً مشکلی ندارد و در صورتی که طراحی برنامه به خوبی انجام شده باشد، اما این کار باعث افزایش مقدار کد Python  می‌شود به جای اینکه کد میان برنامه و رویه‌های ذخیره‌شده پایگاه داده تقسیم شود.

پیاده‌سازی‌های ORM پایتون

پیاده‌سازی‌های مختلفی از ORM در پایتون وجود دارد که شامل موارد زیر است:

  • SQLAlchemy
  • Peewee
  • Django ORM
  • PonyORM
  • SQLObject
  • Tortoise ORM  (کد منبع)

ORMهای دیگری نیز وجود دارند، مانند Canonical’s Storm  ، اما بیشتر آن‌ها به نظر نمی‌رسد که در حال حاضر تحت توسعه فعال باشند. در ادامه، بیشتر در مورد ORMهای فعال و اصلی یاد خواهید گرفت.

Django ORM

فریم‌ورک وب Django با یک ماژول مربوط به نقشه‌برداری شیء-رابطی داخلی همراه است که معمولاً به عنوان “Django ORM” یا “ORM Django” شناخته می‌شود.

Django ORM  برای عملیات پایگاه داده ساده و متوسط خوب عمل می‌کند. با این حال، اغلب شکایت‌هایی وجود دارد که ORM  انجام کوئری‌های پیچیده را خیلی پیچیده‌تر از نوشتن SQL ساده یا استفاده از SQLAlchemy می‌کند.

از نظر فنی، ممکن است به SQL پایین بیایید اما این کار کوئری‌ها را به یک پیاده‌سازی پایگاه داده خاص می‌بندد. ORM به شدت با Django گره خورده است و جایگزینی ORM پیش‌فرض با SQLAlchemy در حال حاضر یک راه‌حل هک است. توجه داشته باشید که ممکن است در آینده امکان استفاده از بک‌اندهای ORM قابل تعویض در Django وجود داشته باشد همانطور که اکنون امکان تغییر موتور قالب برای رندر کردن خروجی در Django وجود دارد.

از آنجا که بیشتر پروژه‌های Django به ORM پیش‌فرض وابسته هستند، بهتر است در مورد موارد استفاده پیشرفته و ابزارهای موجود برای انجام بهترین کار در داخل فریم‌ورک موجود مطالعه کنید.

SQLAlchemy ORM

SQLAlchemy یک ORM محبوب پایتون است زیرا سطح توزیعی را “درست” انتخاب کرده و به نظر می‌رسد در اکثر موارد نوشتن کوئری‌های پیچیده پایگاه داده را آسان‌تر از Django ORM می‌کند. اگر می‌خواهید بیشتر در مورد استفاده از این کتابخانه یاد بگیرید یک صفحه کامل در مورد SQLAlchemy وجود دارد که باید مطالعه کنید.

Peewee ORM

Peewee یک پیاده‌سازی ORM در پایتون است که برای “ساده‌تر، کوچکتر و قابل هک‌تر” بودن نسبت به SQLAlchemy نوشته شده است. برای اطلاعات بیشتر در مورد پیاده‌سازی ORM پایتون، صفحه کامل Peewee را بخوانید.

Pony ORM

Pony ORM یک ORM دیگر پایتون است که به صورت متن‌باز تحت مجوز Apache 2.0 در دسترس است.

SQLObject ORM

SQLObject یک ORM است که بیش از ۱۴ سال است که تحت توسعه فعال متن‌باز قرار دارد، از قبل از سال ۲۰۰۳.

مهاجرت‌های ساختار پایگاه داده

مهاجرت‌های ساختار پایگاه داده، مانند زمانی که نیاز به اضافه کردن یک ستون جدید به جدول موجود در پایگاه داده خود دارید، به طور فنی بخشی از ORMها نیستند. با این حال، از آنجا که ORMها معمولاً به یک رویکرد بی‌دست‌وپای پایگاه داده منجر می‌شوند (که در بسیاری از موارد برای توسعه‌دهندگان خطرناک است)، کتابخانه‌هایی برای انجام مهاجرت‌های ساختار اغلب همراه با استفاده از ORM در پروژه‌های برنامه وب وجود دارند.

منبع متن:

https://www.fullstackpython.com/object-relational-mappers-orms.html

محمد صداقتی
Latest posts by محمد صداقتی (see all)
, , , , , ,

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *