Database ကို သင့် App သို့ ထည့်နည်း (နောင်တွင် ဒေတာ မဆုံးရှုံးစေရန်)
အက်ပ်သို့ database ထည့်ရန် managed relational database (ပုံမှန်အားဖြင့် Postgres) ကို ရွေးပါ၊ ၎င်း၏ connection string ကို server-side secret အဖြစ် သိမ်းပါ၊ သင်သိမ်းမည့် အမျိုးအစားတစ်ခုစီအတွက် ဇယားတစ်ခုစီ ဖန်တီးပါ၊ ထို့နောက် သင့် backend (browser မဟုတ်ဘဲ) က ဒေတာကို ဖတ်ရေးစေပါ။ AI app builder ဖြင့် တည်ဆောက်ပါက "ဒီဒေတာကို database ထဲ သိမ်းပါ" ဟု ပြောရုံဖြင့် agent က ဇယားများနှင့် code ကို ပြင်ဆင်ပေးနိုင်သည်။ သင့်တာဝန်မှာ ဒေတာကို ရှင်းရှင်းလင်းလင်း ဖော်ပြပြီး ၎င်း တကယ် သိမ်းဆည်းခံရကြောင်း စစ်ဆေးခြင်း ဖြစ်သည်။
ဤလမ်းညွှန်တွင် database ကို ဘယ်အချိန် လိုအပ်သလဲ၊ အဓိက ရွေးချယ်စရာများ၊ ဒေတာကို ဘယ်လို ဖော်ပြရမလဲ နှင့် ဒေတာ ဆုံးရှုံးခြင်း သို့မဟုတ် ယိုစိမ့်ခြင်း ဖြစ်စေသော အမှားများကို ဖော်ပြထားသည်။
App သည် database ဘယ်အချိန် လိုအပ်သလဲ
app သည် စာမျက်နှာပိတ်ပြီးနောက်ပင် တစ်ခုခုကို မှတ်ထား ရန် သို့မဟုတ် လူများကြား ဒေတာကို မျှဝေ ရန် လိုအပ်သောအခါ database လိုအပ်ပါသည်။ ပုံမှန် လက္ခဏာများမှာ-
- ဧည့်သည်များက တစ်ခုခု တင်ပြသည်- ပုံစံ၊ sign-up၊ booking၊ order
- အသုံးပြုသူများတွင် ကိုယ်ပိုင် သိမ်းထားသော အကြောင်းအရာရှိသည့် account များ ရှိသည်
- admin က အခြားသူများ ဖန်တီးထားသည်များကို ကြည့်ရန် သို့မဟုတ် ပြင်ရန် လိုသည်
- အချိန်ကြာလာသည်နှင့်အမျှ အစီရင်ခံစာ သို့မဟုတ် ရေတွက်မှုများ လိုချင်သည်
အကြောင်းအရာတူတူကို လူတိုင်းကို ပြသသည့် static site (portfolio သို့မဟုတ် ရိုးရှင်းသော landing page ကဲ့သို့) အတွက် မလိုအပ်ပါ။ database ဆိုတာ ဘာလဲ မသေချာပါက ပထမဆုံး database ဆိုတာ ဘာလဲ ကို ဖတ်ပါ။
ရွေးချယ်စရာများ
| ရွေးချယ်မှု | ဘာလဲ | အကောင်းဆုံး အသုံးချပုံ | အားနည်းချက်များ |
|---|---|---|---|
| AI app builder မှ built-in database | သင့် project အတွက် ဖန်တီးပြီး ချိတ်ဆက်ထားသော database | AI builder ဖြင့် တည်ဆောက်သော app အများစု | ထို platform ၏ hosting တွင် မှီခိုသည်။ export နှင့် backup သည် platform ပေါ် မူတည်သည် |
| Managed Postgres သို့မဟုတ် MySQL | သီးသန့် မှာယူရသော hosted relational database | ကိုယ်တိုင် host လုပ်သော app များ သို့မဟုတ် ဝန်ဆောင်မှုများ မျှဝေသုံးသော app များ | key များ၊ connection ကန့်သတ်ချက်များနှင့် plan များကို သင် စီမံရသည် |
| Backend-as-a-service | Database၊ auth၊ storage နှင့် API များ တစ်ခုတည်းတွင် | ဆိုဒ်ရှေ့ပိုင်း (frontend) အများစု ပါသော app ဖြစ်ပြီး login အဆင်သင့် လိုချင်သူများ | platform-specific သဘောတရား ပိုသင်ရသည် |
| Document (NoSQL) database | ပြောင်းလဲနိုင်သော JSON ကဲ့သို့ document များ သိမ်းသည် | အလွန် ပုံစံမတူသော ဒေတာ | ဆက်စပ်မှုများနှင့် အစီရင်ခံခြင်း ခက်သည် |
| Spreadsheet ကို database အဖြစ် | API မှတစ်ဆင့် Google Sheets စသည် | အသေးစား internal tool များ၊ prototype များ | နှေးသည်၊ ကန့်သတ်ချက် အစစ်အမှန် မရှိ၊ တစ်ပြိုင်နက် ပြင်ဆင်မှုတွင် ပျက်သည် |
အသေးစားမှ အလတ်စား web app အများစုအတွက် Postgres ကဲ့သို့ relational database သည် မှန်ကန်သော ပုံမှန်ရွေးချယ်မှု ဖြစ်သည်။ ဆက်စပ်မှုများ (customer တစ်ယောက်တွင် order များစွာ ရှိသည်) ကို ကောင်းစွာ ကိုင်တွယ်ပြီး ဒေတာ တသမတ်တည်း ရှိစေကာ နောက်ပိုင်း SQL ဖြင့် မေးခွန်းများ မေးနိုင်သည်။ Postgres ၏ ရိုးရှင်းသော ရှင်းလင်းချက်အတွက် Postgres ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။
မတည်ဆောက်မီ ဒေတာကို ဖော်ပြပါ
အကောင်းဆုံးလုပ်နိုင်သည့်အရာမှာ app သိမ်းမည့် အရာများ နှင့် ၎င်းတို့ ဘယ်လို ဆက်စပ်သလဲ ကို ရေးချခြင်း ဖြစ်သည်။ database ဝေါဟာရ လိုအပ်ပါ။ booking app တစ်ခုအတွက်-
- Customers- နာမည်၊ အီးမေးလ်၊ ဖုန်း
- Services- အမည်၊ ကြာချိန်၊ စျေးနှုန်း
- Bookings- ဘယ် customer၊ ဘယ် service၊ စတင်ချိန်၊ အခြေအနေ (pending၊ confirmed၊ cancelled)
ဤသည်မှာ ဇယား သုံးခု ဖြစ်သည်။ "ဘယ် customer" နှင့် "ဘယ် service" တို့သည် ဇယားများကြား link (foreign key) များ ဖြစ်လာသည်။ ဤအရာကို စောစောစီးစီး မှန်ကန်စွာ လုပ်ခြင်းသည် နည်းပညာရွေးချယ်မှုထက် အရေးကြီးသည်၊ အကြောင်းမှာ အတန်းများ ရှိနေပြီးသော ဒေတာ၏ ပုံစံကို ပြောင်းရန်မှာ စာမျက်နှာ layout ပြောင်းခြင်းထက် ခက်ခဲသောကြောင့် ဖြစ်သည်။
လက်တွေ့ စည်းမျဉ်းအချို့-
- အမျိုးအစားတစ်ခုစီအတွက် ဇယားတစ်ခု။ order များကို customer ပေါ်ရှိ စာသား column တစ်ခုတွင် မထည့်ပါနှင့်။
- အတန်းတိုင်းတွင် ID နှင့် created-at အချိန် ထည့်ပါ။ နောက်ပိုင်း နှစ်ခုလုံး လိုအပ်လာမည်။
- မှန်ကန်သော type များ သုံးပါ။ ရက်စွဲကို date အဖြစ်၊ ငွေကို စင့် (cent) အရေအတွက် သို့မဟုတ် decimal အဖြစ် သိမ်းပါ၊ စာသားအဖြစ် မသိမ်းပါနှင့်။
- လိုအပ်သော field များကို required အဖြစ် မှတ်ပါ။ ပုံစံက သာမက database ကိုယ်တိုင် မှားသော ဒေတာကို ပယ်ချစေပါ။
ဥပမာ prompts
ဇယားတစ်ခုလုံး တစ်ကြိမ်တည်း မချပါနှင့်၊ feature တစ်ခုချင်းစီ စတင်ပါ-
ဤ app သို့ database ထည့်ပါ။ customer name၊ email၊ service၊ start time နှင့် status (pending၊ confirmed၊ cancelled၊ default pending) ပါသော bookings ဇယား ဖန်တီးပါ။ booking form မှ တင်သွင်းချက်များကို ထိုဇယားသို့ သိမ်းပါ၊ အောင်မြင်ကြောင်း message ပြပါ၊ အသစ်ဆုံး ကို အပေါ်ဆုံးထားသည့် bookings စာရင်းပါသော admin စာမျက်နှာ ထည့်ပါ။
ထို့နောက် တိုးချဲ့ပါ-
services ဇယား (အမည်၊ ကြာချိန် မိနစ်၊ စျေးနှုန်း cent ဖြင့်) ထည့်ပါ။ bookings ပေါ်ရှိ free-text service field ကို services သို့ link ဖြင့် အစားထိုးပါ၊ ရှိပြီးသား bookings များကို မဖျက်ဘဲ migrate လုပ်ပါ။
ပိုတင်းကျပ်စေပါ-
database ဖတ်ခြင်းနှင့် ရေးခြင်းအားလုံး server ပေါ်တွင်သာ ဖြစ်စေပါ။ browser သည် database connection string ကို ဘယ်တော့မှ မလက်ခံရပါစေနှင့်။ insert မလုပ်မီ email နှင့် start time ကို server ပေါ်တွင် အတည်ပြုပါ။
အဆင့်လိုက် လုပ်ဆောင်ပုံ
- ဒေတာကို စာရင်းပြုစုပါ အထက်ပါအတိုင်း- အရာများ၊ field များ၊ ၎င်းတို့အကြား ဆက်စပ်မှုများ။
- Database ကို ဖန်တီးပါ။ AI builder တွင် chat ထဲ တောင်းဆိုပါ။ အခြားနေရာတွင် managed Postgres instance ဖန်တီးပြီး connection string ကို ကူးပါ။
- Connection string ကို secret အဖြစ် သိမ်းပါ (server ပေါ်ရှိ environment variable)၊ code ထဲ တစ်ခါမှ မထည့်ပါနှင့်။ environment variables နှင့် secrets ကို ကြည့်ပါ။
- ဇယားများ ဖန်တီးပါ။ migration များကို အသုံးပြုပါ- schema ပြောင်းလဲမှုများကို ထပ်ခါတလဲလဲ ပြန်လုပ်နိုင်ပြီး ပြန်ဖျက်နိုင်သော version ပါသည့် script များ။
- Server route များ တည်ဆောက်ပါ ဒေတာကို ဖန်တီး၊ ဖတ်၊ ပြင်၊ ဖျက် (CRUD) လုပ်နိုင်ရန်။ browser သည် ဤ route များကို ခေါ်ပြီး database ကို တိုက်ရိုက် မဆက်သွယ်ပါ။
- UI ကို route များနှင့် ချိတ်ဆက်ပါ- သိမ်းသော ပုံစံများ၊ ဖတ်သော စာရင်းများ၊ ဘာမျှမရှိသောအခါ empty state။
- ဒေတာ တည်မြဲမှုကို စမ်းပါ။ တစ်ခုခု တင်ပါ၊ စာမျက်နှာကို ပြန်ဖွင့်ပါ၊ browser တစ်ခုခြားတွင် ဖွင့်ပါ။ ဒေတာ မရှိလျှင် database ထဲ မသိမ်းခဲ့ပါ။
- ဝင်ရောက်ခွင့် စစ်ဆေးပါ။ အသုံးပြုသူ ဒုတိယယောက်အဖြစ် ဝင်ပြီး ပထမအသုံးပြုသူ၏ ဒေတာကို မမြင်နိုင်ကြောင်း၊ မပြင်နိုင်ကြောင်း အတည်ပြုပါ။
- Publish လုပ်ပြီး ထပ်စမ်းပါ live URL တွင်၊ ထုတ်ပြန်ထားသော app သည် preview နှင့် မတူသော connection သုံးနိုင်သောကြောင့် ဖြစ်သည်။
အဖြစ်များသော အမှားများ
- Browser တွင် သိမ်းပြီး database တွင် သိမ်းပြီးဟု ထင်ခြင်း။ localStorage သည် အလုပ်လုပ်သလို ထင်ရသော်လည်း တစ်ခြား စက်တွင် ဖွင့်လိုက်သည်နှင့် ပျောက်သွားနိုင်သည်။ အမြဲတမ်း browser ဒုတိယတစ်ခုတွင် စမ်းပါ။
- Connection string ကို frontend code ထဲ ထည့်ခြင်း။ frontend code ကို မည်သူမဆို ဖတ်နိုင်သည်။ ထိုသို့ဆိုလျှင် သင့် database တစ်ခုလုံး ၎င်းတို့ လက်ထဲ ရောက်သွားမည်။
- Access စစ်ဆေးချက် မရှိခြင်း။ "ကျွန်တော့် order များ ပြပါ" သည် ဝင်ထားသော အသုံးပြုသူဖြင့် server ပေါ်တွင် စစ်ထားရမည်၊ UI တွင် မစစ်ပါနှင့်။ ၎င်းသည် AI ဖြင့် တည်ဆောက်သော app များတွင် အဖြစ်အများဆုံး လုံခြုံရေး အပေါက်ဖြစ်သည်။ လုံခြုံရေး checklist တွင် ဖုံးလွှမ်းထားသည်။
- အန္တရာယ်ရှိသော schema ပြောင်းလဲမှုများ။ "table ကို နာမည်ပြောင်းပါ" သို့မဟုတ် "ဖွဲ့စည်းပုံ ပြောင်းပါ" ဟု တောင်းဆိုခြင်းသည် ဇယားကို ဖျက်ပြီး ပြန်ဖန်တီးနိုင်သည်။ ဒေတာ အစစ်အမှန် ရှိနေပါက "ရှိပြီးသား အတန်းများကို migrate လုပ်ပါ၊ ဘာမျှ မဖျက်ပါနှင့်" ဟု ပြောပါ။
- ဖိုင်များကို database ထဲ သိမ်းခြင်း။ ပုံများနှင့် PDF များသည် file storage တွင် ရှိသင့်ပြီး table တွင် URL သို့မဟုတ် key သာ သိမ်းပါ။ file upload ထည့်နည်း ကို ကြည့်ပါ။
- Backup မရှိခြင်း။ customer မရှိမီ သင့် platform က ဒေတာကို ဘယ်လို backup လုပ်သလဲ၊ ဘယ်လို restore လုပ်သလဲ သိထားပါ။
Checklist
- အမျိုးအစားတစ်ခုစီတွင် ကိုယ်ပိုင် ဇယားနှင့် ID နှင့် created-at အချိန်ရှိသည်
- လိုအပ်သော field များနှင့် type များကို database က တင်းကျပ်စွာ ထိန်းသည်
- Connection string သည် server-side secret များတွင်သာ ရှိသည်
- ဖတ်ရေး အားလုံး server route များမှတစ်ဆင့်သာ ဖြစ်သည်
- အသုံးပြုသူတစ်ယောက်စီသည် ကိုယ်ပိုင် row များကိုသာ ဖတ်ပြင်နိုင်သည်
- ဒေတာသည် စာမျက်နှာ ပြန်ဖွင့်ပြီးနောက်ရော browser တစ်ခုခြားတွင်ပါ ရှိနေသည်
- Schema ပြောင်းလဲမှုများသည် migration များ သုံးပြီး ရှိပြီးသား အတန်းများကို ထိန်းသည်
- Backup နှင့် restore လုပ်ပုံကို သိထားသည်
- Publish လုပ်ပြီးနောက် live app ကို စမ်းပြီးပြီ
Mythex တွင် database ထည့်ခြင်း
Mythex တွင် project တစ်ခုစီသည် သီးသန့် Postgres database ကို Free နှင့် Pro နှစ်ခုလုံးတွင် ရယူနိုင်သည်။ သီးသန့် "attach" ခလုတ် နှိပ်ရန် မလိုအပ်ပါ- chat တွင် "email စာရင်းကို database ထဲ သိမ်းပါ" ဟု ရေးပါ သို့မဟုတ် /database ဟု ရိုက်ပါ၊ connection အချက်အလက်များကို workspace နှင့် ထုတ်ပြန်ထားသော app သို့ ထည့်ပေးမည်။ Project settings တွင် database active ရှိမရှိ ပြသည်။
Database သည် အချိန် ၅ မိနစ် အလုပ်မလုပ်ပါက အိပ်သွားပြီး နောက်တောင်းဆိုမှုတွင် နိုးလာသည်။ Published အသုံးပြုမှုကို အမှန်တကယ် နိုးနေသော အချိန်အတွက်သာ ကောက်ခံပြီး တည်ဆောက်ရာတွင် သုံးသော credit လက်ကျန်မှ ယူသည်။ ထုတ်ပြန်ပြီးနောက် database ထည့်ပါက live app က ရရှိစေရန် ထပ်မံ publish လုပ်ပါ။
အသေးစိတ်အတွက် docs ရှိ Database နှင့် CRUD app တည်ဆောက်ခြင်း recipe ကို ကြည့်ပါ။ အသုံးပြုသူတစ်ဦးချင်းစီ၏ ဒေတာ၏ login ဘက်ကို စိတ်ဝင်စားပါက app သို့ login ထည့်နည်း ကို ဖတ်ပါ။
မေးခွန်းများ
ကျွန်တော့် app အတွက် database လိုအပ်ပါသလား?
app သည် စာမျက်နှာပိတ်ပြီးနောက် တစ်ခုခုကို မှတ်ထားရန် သို့မဟုတ် လူများကြား ဒေတာ မျှဝေရန် လိုအပ်သည်နှင့် database လိုအပ်လာပါပြီ။ sign-up၊ order၊ booking၊ post သို့မဟုတ် settings တို့ ဥပမာ ဖြစ်သည်။ လူတိုင်းကို တူညီသော အကြောင်းအရာ ပြသသည့် static website အတွက် မလိုအပ်ပါ။
သေးငယ်သော web app အတွက် ဘယ် database ကို သုံးသင့်သလဲ?
Postgres ကဲ့သို့ relational database သည် အသေးစား web app အများစုအတွက် ယုံကြည်ရသော ရွေးချယ်မှု ဖြစ်သည်။ အသုံးပြုသူများ၊ order များနှင့် ဆက်စပ်မှုများကို ကောင်းစွာ ကိုင်တွယ်ပြီး အစီရင်ခံစာများကိုလည်း လွယ်ကူစွာ ထုတ်နိုင်သည်။ သေးငယ်သော အတိုင်းအတာတွင် ကျော်လွန်ရန် ခဲသည်။
Database အစား browser ထဲတွင် ဒေတာ သိမ်းနိုင်ပါသလား?
localStorage ကဲ့သို့ browser storage သည် စက်တစ်လုံး၊ browser တစ်ခုတည်းတွင်သာ ရှိပြီး အသုံးပြုသူက အချိန်မရွေး ရှင်းလင်းနိုင်သည်။ theme ရွေးချယ်မှုကဲ့သို့ ဦးစားပေးချက်များအတွက် သင့်တော်သော်လည်း သင်သို့မဟုတ် အခြားသူများ နောက်မှ မြင်ရမည့် အရာများအတွက် မသင့်ပါ။
Mythex တွင် database ပါသလား?
ပါပါသည်။ Mythex project တစ်ခုစီသည် Free နှင့် Pro တွင် သီးသန့် Postgres database ရနိုင်သည်။ chat တွင် တောင်းဆိုခြင်း သို့မဟုတ် /database command ကို အသုံးပြုခြင်းဖြင့် ရယူနိုင်ပြီး connection အချက်အလက်များကို အလိုအလျောက် ထည့်ပေးသည်။ အသုံးပြုမှုကို တည်ဆောက်ခြင်းနှင့် တူညီသော credit လက်ကျန်မှ ပေးချေသည်။