လွယ်လွယ်ပြောရရင် ORM ဆိုတာ Database ကို SQL စာကြောင်း အရှည်ကြီးတွေ မရေးဘဲ ကိုယ်သုံးနေတဲ့ Programming Language နဲ့ပဲ ပြောလို့ရအောင် လုပ်ပေးတဲ့ အလွှာတစ်ခု ဖြစ်တယ်။ ORM က Object-Relational Mapping ရဲ့ အတိုကောက်ပါ။ Django ရဲ့ ORM, SQLAlchemy, Prisma, Hibernate လို Tool တွေက ဒီအမျိုးအစားပဲ။
ကျွန်တော် ပထမဆုံး Django နဲ့ Web App ရေးတုန်းက အံ့ဩခဲ့ရတယ်။ Database Table တစ်ခု ဖန်တီးဖို့ SQL တစ်ကြောင်းမှ မရေးရဘူး။ Python Class တစ်ခု ရေးလိုက်ရုံပဲ။ အဲဒီ Class က Table ဖြစ်သွားတယ်။ User အသစ်တစ်ယောက် သိမ်းချင်ရင် User.objects.create(name="Min") လို့ ရေးရုံပဲ။ ဒါဟာ Database နဲ့ စကားပြောတဲ့ နည်းလမ်းကို လုံးဝ ပြောင်းပစ်လိုက်တာပဲ။
SQL နဲ့ တိုက်ရိုက်ရေးရင် ဘာဖြစ်လဲ?
စာကြည့်တိုက်မှူးကို ဥပမာယူကြည့်ရအောင်။ SQL နဲ့ တိုက်ရိုက်ရေးတာက စာကြည့်တိုက်မှူးကို စာရွက်နဲ့ တိတိကျကျ ညွှန်ကြားချက်ပေးရသလိုပဲ။
SELECT * FROM users WHERE age > 18 ORDER BY name;ဒါက မဆိုးပါဘူး။ ဒါပေမယ့် App က ကြီးလာရင် SQL စာကြောင်းတွေက အများကြီးဖြစ်လာတယ်။ Table တွေ ချိတ်ဆက်ရတာ၊ Data တွေ ထည့်ရတာ၊ ပြင်ရတာ — အားလုံးက String အနေနဲ့ Code ထဲမှာ ပြန့်နေတယ်။ စာလုံးတစ်လုံး မှားရင် Run မှ Error တက်တယ်။ Editor ကလည်း ကူမစစ်ပေးဘူး။
ORM နဲ့ဆိုရင် အဲဒီအလုပ်ကို Python (ဒါမှမဟုတ် ကိုယ်သုံးတဲ့ Language) နဲ့ပဲ ရေးတယ်။
users = User.objects.filter(age__gt=18).order_by("name")အဓိပ္ပာယ်က အတူတူပဲ။ ဒါပေမယ့် ဒါက Python Code အစစ်ဖြစ်တော့ Editor က အမှားကို ကြိုစစ်ပေးတယ်၊ Auto-complete လည်း ရတယ်။
ORM က ဘာတွေ လုပ်ပေးလဲ?
Table ကို Class အဖြစ် ပြောင်းပေးတယ် — User Class က users Table ဖြစ်တယ်။ Class ရဲ့ Attribute တစ်ခုချင်းစီက Table ရဲ့ Column တစ်ခုဖြစ်တယ်။
SQL ကို အလိုလို ရေးပေးတယ် — ကိုယ်က Python နဲ့ ပြောလိုက်ရင် ORM က နောက်ကွယ်မှာ SQL အဖြစ် ဘာသာပြန်ပြီး Database ကို ပို့ပေးတယ်။
Database ပြောင်းရတာ လွယ်တယ် — SQLite ကနေ PostgreSQL ကို ပြောင်းချင်ရင် Code အများကြီး ပြန်ရေးစရာ မလိုဘူး။ Setting တစ်နေရာလောက် ပြောင်းရုံပဲ။
Security ကို ကူညီပေးတယ် — ORM က Parameter တွေကို သူ့ဟာသူ သန့်စင်ပေးတော့ SQL Injection လို တိုက်ခိုက်မှုကနေ တော်တော် ကာကွယ်ပြီးသား ဖြစ်တယ်။
ORM ရဲ့ အားနည်းချက်တွေကော?
ORM က မှော်ပညာ မဟုတ်ဘူး။ အားနည်းချက်တွေလည်း ရှိတယ်။
နှေးတတ်တယ် — ORM က ရေးပေးတဲ့ SQL က လူကိုယ်တိုင် ရေးတဲ့ SQL လောက် အမြဲ ထိရောက်တာ မဟုတ်ဘူး။ Data အများကြီး ဆွဲတဲ့အခါ မလိုအပ်တဲ့ Query တွေ အထပ်ထပ် ထွက်သွားတတ်တယ်။ ဒါကို N+1 Problem လို့ ခေါ်တယ်။ Loop ထဲမှာ User တစ်ယောက်ချင်းစီအတွက် Query ထပ်ထပ်ထွက်တာမျိုး။
ရှုပ်ထွေးတဲ့ Query မှာ ခက်တယ် — Report အတွက် Table ၅ ခုချိတ်ပြီး Aggregate လုပ်တဲ့ Query မျိုးဆို SQL နဲ့ တိုက်ရိုက်ရေးတာက ပိုရှင်းတယ်။ ORM နဲ့ ရေးရင် ဖတ်ရခက်သွားတတ်တယ်။
SQL ကို လုံးဝ မသိရင် ဒုက္ခရောက်တယ် — ORM က SQL ကို ဖုံးပေးထားပေမယ့် နောက်ကွယ်မှာ ဘာဖြစ်နေလဲ နားမလည်ရင် Performance ပြဿနာ တက်တဲ့အခါ ဘာပြင်ရမလဲ မသိဘူး။
ဘယ်အချိန်မှာ ORM သုံးသင့်လဲ၊ ဘယ်အချိန်မှာ SQL တိုက်ရိုက်ရေးသင့်လဲ?
ကျွန်တော့်အတွေ့အကြုံအရတော့ ရိုးရိုးရှင်းရှင်း CRUD အလုပ်တွေ — ထည့်တာ၊ ဖတ်တာ၊ ပြင်တာ၊ ဖျက်တာ — ဆိုရင် ORM က အကောင်းဆုံးပဲ။ မြန်တယ်၊ သန့်တယ်၊ အမှားနည်းတယ်။
ဒါပေမယ့် Data အများကြီးနဲ့ ရှုပ်ထွေးတဲ့ Report Query တွေ၊ Performance အရမ်းအရေးကြီးတဲ့ နေရာတွေမှာတော့ SQL ကို တိုက်ရိုက်ရေးတာ ပိုကောင်းတယ်။ Tool ကောင်းတွေက ဒီနှစ်ခုလုံးကို တွဲသုံးလို့ရအောင် လုပ်ပေးထားတယ်။ Django ORM မှာလည်း Raw SQL ရေးလို့ရတယ်။ SQLAlchemy မှာလည်း ဒီလိုပဲ။
အရေးကြီးဆုံးကတော့ ORM ကို သုံးရင် နောက်ကွယ်က SQL ကို တစ်ခါတလေ ကြည့်တတ်ဖို့ပဲ။ Query တွေ ဘယ်လောက် ထွက်နေလဲ၊ ဘယ် Query က နှေးနေလဲ သိရင် ORM က အဖော်ကောင်းတစ်ယောက် ဖြစ်လာမယ်။ မသိရင်တော့ အနက်ရောင် ဗူးကြီးတစ်လုံး ဖြစ်သွားမယ်။
ဒါပါပဲ။ ORM ဆိုတာ Database ကို ကိုယ့်ဘာသာစကားနဲ့ ပြောလို့ရအောင် လုပ်ပေးတဲ့ ဘာသာပြန်တစ်ယောက်ပဲ။ ဘာသာပြန်ကောင်းကောင်းရှိရင် အလုပ်မြန်တယ် — ဒါပေမယ့် ဘာသာပြန်နောက်မှာ ဘာဖြစ်နေလဲ တစ်ခါတလေ လှည့်ကြည့်ဖို့ မမေ့နဲ့။ 🙂
