လေ့ကျင့်ခန်း — ဒေတာဘေ့စ် Glossary နှင့် ရွေးချယ်ရေး လမ်းညွှန်

နားလည်ထားရမယ့် အချက်

ဒီ closing lesson က အလုပ်နှစ်ခု လုပ်ပါတယ်။ ပထမအချက်က course က term အားလုံးကို glossary တစ်ခုတည်းထဲမှာ စုစည်းပေးတာနဲ့ database type/product ချိတ်ဆက်ပေးတဲ့ decision guide တစ်ခုပါ။ ဒုတိယအချက်က UPDATE/DELETE run ခင် လိုက်နာသင့်တဲ့ query safety checklist ပါ။

ဒီ checklist ရှိရတဲ့ အကြောင်းရင်းက ဈေးအကြီးဆုံး database အမှားတွေဟာ ရှားပါးတဲ့ attack မဟုတ်ဘဲ environment မှား၊ WHERE clause ပိုကိုက်နေ၊ backup မယူထား၊ transaction မရှိတဲ့ ပုံမှန် UPDATE/DELETE statement တွေသာ ဖြစ်လေ့ရှိလို့ပါ။

Pre-flight checklist လို ဆက်ဆံပါ

ကိုယ့်ကျွမ်းကျင်မှုကို မယုံကြည်လို့ မဟုတ်ဘဲ၊ time pressure အောက်မှာ ဖမ်းမိရခက်တဲ့ small assumption error ကို ဖမ်းမိစေမယ့် fixed routine တစ်ခုအနေနဲ့ဆက်ဆံပါ။

ဒီ exercise ထဲက scenario သုံးခုက ပုံမှန်ဆန်တဲ့ situation တွေမှာ checklist အတူတူကို ကျင့်သုံးခိုင်းတာဖြစ်ပြီး၊ ဒါဟာ checklist အရေးအကြီးဆုံး အချိန်ပါပဲ။

text

QUERY SAFETY CHECKLIST -- DECISION FLOW
---------------------------------------
QUERY SAFETY CHECKLIST -- DECISION FLOW
-----
[ About to run an UPDATE or DELETE ]
        |
        v
Correct database/environment?   --no--> STOP: fix connection
        | yes
        v
Correct table confirmed?        --no--> STOP: re-check table
        | yes
        v
WHERE clause reviewed?          --no--> STOP: review WHERE
        | yes
        v
Expected row count known?       --no--> run SELECT to check
        | yes
        v
Backup/snapshot taken if needed?--no--> STOP: take one first
        | yes
        v
Transaction available/used?     --no--> wrap query in one
        | yes
        v
Tested with SELECT first?       --no--> test it first
        | yes
        v
   [ Proceed with UPDATE/DELETE ]

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အထက်က worked answer key ကို scenario သုံးခုစလုံးအတွက် တစ်ခုတည်းသော အစီအစဉ်ရှိသလို မယူဆဘဲ ဖော်ပြထားပါတယ်။

Scenario 1 — Category-wide discount UPDATE

အန္တရာယ်အများဆုံး item နှစ်ခုက WHERE clause နဲ့ row count ဖြစ်ပါတယ်။ archived (သို့) out-of-stock item တွေကို မထင်မှတ်ဘဲ ကိုက်နိုင်တာကြောင့် WHERE ကို SELECT အနေနဲ့ အရင် run ပြီး row count ကို ယှဉ်ကြည့်ကာ transaction ထဲမှာ run ပါ။

Scenario 2 — Old log entries DELETE

အဓိက အန္တရာယ်က date boundary နဲ့ environment အတည်ပြုမှုပါ။ connection target ကို ပြတ်သားစွာ အတည်ပြုပြီး SELECT COUNT ဖြင့် row count ကြည့်ကာ table သေးငယ်မှမဟုတ်ရင် snapshot အရင်ယူပါ။

Scenario 3 — Required column migration

အရေးကြီးဆုံး item က existing row တွေကို ဘာဖြစ်စေမလဲဆိုတာပါ — default value မပါသော NOT NULL constraint က row အဟောင်းအပေါ် fail ဖြစ်စေနိုင်ပါတယ်။ backup ယူပြီး production copy တစ်ခုအပေါ် migration ကို အရင်စမ်းသပ်ပါ။

database မှားယွင်းမှုအကုန်ဆုံးအများစုက exotic attack တွေ မဟုတ်ဘဲ environment, WHERE clause, row count မစစ်ဘဲ run လိုက်တဲ့ ပုံမှန် UPDATE/DELETE statement တွေသာ ဖြစ်ပါတယ်။
glossary နဲ့ decision guide တွေက vocabulary နဲ့ product ရွေးချယ်မှုအတွက် starting point များသာဖြစ်ပြီး rule မဟုတ်ပါ — project တစ်ခုအတွက် database မှန်ကန်မှုသည် access pattern နဲ့ constraint အမှန်အပေါ် မူတည်ဆဲဖြစ်သည်။
WHERE clause ကို SELECT အနေနဲ့ အရင် run ကြည့်ပြီး row count မျှော်မှန်းထားသလား စစ်ဆေးတာက အပျက်အစီးအနည်းဆုံးဖြစ်စေတဲ့ တန်ဖိုးအသက်ဆုံး habit ဖြစ်ပါတယ်။

Query Safety Checklist — UPDATE/DELETE မလုပ်ခင်

မှန်ကန်သော database/environment ကို အတည်ပြုပြီးပြီလား
မှန်ကန်သော table ကို အတည်ပြုပြီးပြီလား
WHERE clause ကို ပြန်လည်စစ်ဆေးပြီးပြီလား
မျှော်မှန်းထားတဲ့ row count ကို သိပြီးပြီလား
လိုအပ်ပါက backup/snapshot ကို ယူထားပြီးပြီလား
ဖြစ်နိုင်သည့်နေရာတွင် transaction ကို အသုံးပြု/ရရှိထားပြီလား
လက်တွေ့ကျရင် SELECT နဲ့ အရင်စမ်းသပ်ပြီးပြီလား

အတူတူ စမ်းရေးကြည့်မယ်

javascript

function checkQuerySafety(queryPlan) {
  const steps = [
    { key: "environmentConfirmed", label: "Confirm correct database/environment" },
    { key: "tableConfirmed", label: "Confirm correct table" },
    { key: "whereClauseReviewed", label: "Review the WHERE clause" },
    { key: "expectedRowCountKnown", label: "Know the expected row count" },
    { key: "hasBackupOrSnapshot", label: "Take a backup/snapshot if needed" },
    { key: "transactionAvailable", label: "Use a transaction where possible" },
    { key: "testedWithSelectFirst", label: "Test with SELECT first where practical" },
  ];

  const missingSteps = steps
    .filter((step) => !queryPlan[step.key])
    .map((step) => step.label);

  return {
    safeToProceed: missingSteps.length === 0,
    missingSteps,
  };
}

const riskyPlan = {
  environmentConfirmed: true,
  tableConfirmed: true,
  whereClauseReviewed: false,
  expectedRowCountKnown: false,
  hasBackupOrSnapshot: false,
  transactionAvailable: false,
  testedWithSelectFirst: false,
};

const safePlan = {
  environmentConfirmed: true,
  tableConfirmed: true,
  whereClauseReviewed: true,
  expectedRowCountKnown: true,
  hasBackupOrSnapshot: true,
  transactionAvailable: true,
  testedWithSelectFirst: true,
};

console.log("Risky plan:", JSON.stringify(checkQuerySafety(riskyPlan)));
console.log("Safe plan:", JSON.stringify(checkQuerySafety(safePlan)));

You should see

riskyPlan အတွက် `{"safeToProceed":false,"missingSteps":["Review the WHERE clause","Know the expected row count","Take a backup/snapshot if needed","Use a transaction where possible","Test with SELECT first where practical"]}` ကို log ထုတ်ပါတယ်။ safePlan အတွက်တော့ `{"safeToProceed":true,"missingSteps":[]}` ကို log ထုတ်ပါတယ်။

၅ မိနစ် စမ်းကြည့်

အထက်က worked answer key ကို မကြည့်မီ ဒီ situation သုံးခုစလုံးအတွက် query safety checklist ကို ကျင့်သုံးကြည့်ပါ။ ပထမတစ်ခု — category တစ်ခုအတွင်းက product အားလုံးရဲ့ discount percentage ကို ပြောင်းမယ့် UPDATE တစ်ခုကို production database အပေါ် တိုက်ရိုက် run ရမည်ဖြစ်သည်။ ဒုတိယတစ်ခု — နှစ်နှစ်ကြာ data စုစည်းလာခဲ့တဲ့ table တစ်ခုမှ ရက် ၉၀ ကျော်ပြီးသား log entry တွေကို DELETE လုပ်တော့မည်ဖြစ်သည်။ တတိယတစ်ခု — row သန်းချီရှိပြီးသား table တစ်ခုထဲသို့ column အသစ် required (NOT NULL) တစ်ခုကို ထည့်ရမည်ဖြစ်သည်။ scenario တစ်ခုစီအတွက် checklist item ခုနစ်ခုကို လိုက်စစ်ပြီး run မခင် သီးခြားစွာ ဘာကို စစ်ဆေး/လုပ်ဆောင်မလဲ ဆုံးဖြတ်ပါ၊ ပြီးတော့ time pressure အောက်မှာ ဘယ် item ကို ကျော်သွားနိုင်ဆုံးလဲ မှတ်ချက်ချပါ။

သတိလေးတစ်ချက်

checklist ကို တကယ်ကျင့်သုံးမည့်အစား တစ်ကြိမ်တည်း ကြည့်ရုံနဲ့ ပြီးတယ်လို့ ယူဆမိတာ — SELECT ကို တကယ်မ run ဘဲ (သို့) WHERE clause ကို တကယ်မစစ်ဘဲ mentally box သာ check လိုက်တာ။

checklist ကို DELETE အတွက်သာ အရေးကြီးတယ်လို့ ယူဆမိတာ — WHERE clause မှားနေတဲ့ UPDATE တစ်ခုက DELETE ထက် row အများကြီးကို တိတ်တဆိတ် ပျက်စီးစေနိုင်သည်။

Evolutionary Database Design (Martin Fowler) — How Databases Work

Database Glossary — အသုံးများသော ဝေါဟာရများ

Term	အဓိပ္ပာယ်
Data	application တစ်ခုက အလုပ်လုပ်ရာမှာသုံးတဲ့ raw fact တွေနဲ့ value တွေ — number၊ text၊ date တို့ — ဖွဲ့စည်းပုံ တစ်ခုခုထဲ မစီစဉ်ရသေးခင်။
Database	application ရဲ့ တစ်ခုထက်ပိုတဲ့ အပိုင်းတွေက တစ်ပြိုင်နက် reliable စွာ store, query, update လုပ်နိုင်တဲ့ data အစုအဝေးတစ်ခု။
DBMS	database ကို တကယ်စီမံခန့်ခွဲပေးတဲ့ software system (PostgreSQL, MongoDB, SQLite စသည်) — disk ပေါ်မှာ data သိမ်းတာ၊ query execute လုပ်တာ၊ constraint နဲ့ access control စတဲ့ rule တွေ enforce လုပ်တာ ပါဝင်သည်။
Table	column အစုတူတူ ပါဝင်တဲ့ row များစုစည်းထားသော name ပါရှိသည့် collection — relational database ရဲ့ အခြေခံ storage unit။
Column	table ထဲက row တိုင်းမှာရှိတဲ့ name ပါ field တစ်ခု — text၊ number၊ date စသည့် data type သတ်မှတ်ထားသည်။
Row	table တစ်ခုထဲက individual record တစ်ခု — column တစ်ခုစီအတွက် value တစ်ခုစီပါဝင်သော set။
Primary Key	table ထဲက row တစ်ခုစီကို ထူးခြားစွာ ဖော်ပြပေးတဲ့ column (သို့) column အစု — row နှစ်ခုက value တူလို့မရပါ။
Foreign Key	table တစ်ခုထဲက column တစ်ခုက table တခြားတစ်ခုရဲ့ primary key ကို reference လုပ်ပြီး နှစ်ခုကြားချိတ်ဆက်ပေးသည်။
Surrogate Key	real-world attribute အစား primary key အဖြစ်သုံးတဲ့ artificial identifier (auto-increment number သို့ generated UUID အများဆုံး) — real-world value တွေက ပြောင်းလဲနိုင်၊ ထပ်နိုင်လို့ပါ။
One-to-One	table တစ်ခုထဲက row တစ်ခုက table တခြားတစ်ခုရဲ့ row တစ်ခုတည်းနဲ့ ကိုက်ညီပြီး ပြန်လည်ကြည့်လျှင်လည်း အတူတူဖြစ်သော relationship။
One-to-Many	table တစ်ခုထဲက row တစ်ခုက table တခြားရဲ့ row အများကြီးနဲ့ ဆက်စပ်နိုင်ပေမယ့် row တစ်ခုစီက မူရင်း row တစ်ခုတည်းနဲ့သာ ပြန်ဆက်စပ်တဲ့ relationship။
Many-to-Many	table တစ်ခုက row အများနဲ့ table တခြားရဲ့ row အများ ဆက်စပ်နိုင်တဲ့ relationship — ပုံမှန်အားဖြင့် ကြားထဲမှာ join table တစ်ခုနဲ့ အကောင်အထည်ဖော်သည်။
Constraint	database ကနေ data အပေါ် automatic ဖြင့် enforce လုပ်တဲ့ rule — value ရှိရမည်၊ unique ဖြစ်ရမည်၊ တခြားနေရာက row ရှိပြီးသားကို reference လုပ်ရမည် စသည်။
NULL	value ပျောက်နေတာ (သို့) မသိတာကို ဖော်ပြတဲ့ special marker — zero မဟုတ်ဘူး၊ empty string လည်းမဟုတ်ဘူး၊ value လုံးဝမရှိတာကိုဆိုလိုသည်။
Normalization	data ထပ်နေမှု လျှော့ချဖို့ table တွေကို key များနဲ့ ချိတ်ဆက်ထားတဲ့ related table များအဖြစ် ခွဲခြမ်းစီစဉ်ခြင်း။
Denormalization	ပုံမှန် query များအတွက် join အရေအတွက် လျှော့ချဖို့ data ကို table များကြား တမင်ထပ်ခြင်း (သို့) ပေါင်းစည်းခြင်း — read speed အတွက် storage နဲ့ update complexity ကို ဖလှယ်ခြင်း။
Query	data ကို ဖတ်ရန်၊ filter လုပ်ရန်၊ ပေါင်းစည်းရန် (သို့) ပြောင်းလဲရန် database ကို တောင်းဆိုတဲ့ request။
CRUD	application တိုင်းလုပ်ဆောင်တဲ့ အခြေခံ data operation လေးမျိုးရဲ့ အတိုကောက် — Create, Read, Update, Delete။
Index	table တစ်ခုလုံးကို scan မလုပ်ဘဲ ကိုက်ညီတဲ့ row တွေကို မြန်မြန်ရှာဖွေပေးတဲ့ သီးခြား data structure — storage ပိုသုံးရပြီး write ပိုနှေးသွားနိုင်သည်။
N+1 Query Problem	list တစ်ခုရအောင် query တစ်ခု run ပြီး list ထဲက item တစ်ခုစီအတွက် query ထပ်လိုက် run နေမိတဲ့ performance bug — ကောင်းစွာ ဒီဇိုင်းလုပ်ထားတဲ့ query အနည်းငယ်ဖြင့် အားလုံးရအောင် မလုပ်ခြင်း။
Transaction	အတူတကွ အောင်မြင်ရမည် (သို့) အတူတကွ ကျရှုံးရမည့် database operation အုပ်စု — data ကို တစ်ဝက်တစ်ပျက် state ထဲ ရောက်မသွားစေရန်။
ACID	relational transaction အများစုက data ကို failure ဖြစ်ခဲ့ရင်ဖြစ်၊ concurrent run ဖြစ်ခဲ့ရင်ဖြစ် မှန်ကန်နေအောင် ပေးထားတဲ့ guarantee လေးခု (Atomicity, Consistency, Isolation, Durability)။
Concurrency	data တစ်ခုတည်းအပေါ် တစ်ချိန်တည်း operation များစွာ ဖြစ်ပေါ်နေခြင်း — database က conflict/update ပျောက်ဆုံးမှုမဖြစ်အောင် သေချာစီမံရသည်။
Isolation	transaction တစ်ခုရဲ့ လုပ်ဆောင်ဆဲ ပြောင်းလဲမှုများကို တစ်ချိန်တည်း run နေတဲ့ transaction တခြားတွေက ဘယ်လောက်မြင်ရသလဲဆိုတာ — ACID guarantee လေးခုထဲက တစ်ခု။
SQL	relational database ထဲက data ကို define, query, modify လုပ်ဖို့ standard language ဖြစ်တဲ့ Structured Query Language။
NoSQL	relational table model ကိုမသုံးတဲ့ database များအတွက် umbrella term — document, key-value, wide-column store များပါဝင်ပြီး schema flexibility (သို့) specific access pattern အတွက် ရွေးလေ့ရှိသည်။
Document Database	data ကို row/column အသေအချာအစား JSON-like document flexible ပုံစံနဲ့ သိမ်းတဲ့ NoSQL database — MongoDB ကဲ့သို့။
Key-Value Database	data ကို unique key တစ်ခုတည်းအလိုက် store/retrieve လုပ်တဲ့ NoSQL database — read/write မြန်ဆန်ဖို့ optimize လုပ်ထား၊ Redis ကဲ့သို့။
SQLite	application ထဲမှာ file တစ်ခုတည်းအနေနဲ့ embed ဖြစ်ပြီး run တဲ့ relational database engine — သီးခြား server process စီမံစရာမလိုပါ။
Embedded Database	network ကနေဆက်သွယ်ရတဲ့ သီးခြား server အနေအစား၊ အသုံးပြုတဲ့ application နဲ့ process တူတူ run တဲ့ database။
Schema	database ရဲ့ ဖွဲ့စည်းပုံ — table, column, type, constraint များ — relational database တွေမှာလို ကြိုတင်တင်းကျပ်စွာ enforce လုပ်တာဖြစ်ဖြစ်၊ NoSQL အများစုလို read time မှာ ပိုပြီး flexible စွာ apply လုပ်တာဖြစ်ဖြစ်။
Access Pattern	application တစ်ခုက data ကို တကယ် ဖတ်/ရေးတဲ့ specific နည်းလမ်း — query ဘာတွေ run သလဲ၊ ဘယ်လောက်ခဏခဏလဲ၊ filter ဘာနဲ့လဲ — schema နဲ့ index ဒီဇိုင်းလုပ်ဖို့ guide အဖြစ်သုံးသည်။
Least Privilege	account (သို့) process တစ်ခုစီကို လုပ်ငန်းလုပ်ဖို့ လိုအပ်တဲ့ access အနည်းဆုံးကိုသာ ပေးပြီး ပိုမပေးတဲ့ security principle။
SQL Injection	untrusted input ကို query ရဲ့ meaning ပြောင်းသွားအောင် ထည့်သွင်းလိုက်တဲ့ attack — attacker က မရသင့်တဲ့ data ကို ဖတ်/ပြင်ခွင့်ရသွားစေသည်။
Parameterized Query	user input ကို query text ထဲ တိုက်ရိုက်မရောဘဲ သီးခြား data အနေနဲ့ ပို့တဲ့ query ရေးနည်း — SQL injection ကို ကာကွယ်ပေးသည်။
Row-Level Security	user (သို့) role တစ်ခုက ဘယ် row တွေကို မြင်/ပြင်နိုင်သလဲဆိုတာကို database layer မှာ automatic ကန့်သတ်ပေးတဲ့ feature — application code ထဲ မဟုတ်ဘဲ။
Connection Pooling	request တိုင်းအတွက် connection အသစ် ဖွင့်မယ့်အစား ဖွင့်ထားပြီးသား database connection အကန့်သတ်ရှိတဲ့ set ကို ထပ်ခါထပ်ခါသုံးခြင်း — ပိုသက်သာပြီး database ကို overload မဖြစ်စေပါ။
Migration	database schema ကို အချိန်ကြာလာတာနဲ့အမျှ ပြောင်းလဲပေးတဲ့ version ရှိ၊ ထပ်ခါသုံးနိုင်တဲ့ script — structure ပြောင်းလဲမှုတွေကို track, review, environment အားလုံးမှာ တသမတ်တည်း apply လုပ်နိုင်စေသည်။
Backup	data ပျောက်ဆုံး/ပျက်စီးသွားရင် database ကို ပြန် restore လုပ်နိုင်ဖို့ အချိန်တစ်ခုမှာ သိမ်းထားတဲ့ data ကော်ပီ။
Replication	database data ကို server အပိုတစ်ခု (သို့) တစ်ခုထက်ပိုသောနေရာသို့ ဆက်တိုက်ကူးယူထားခြင်း — redundancy, read scaling, ဒါမှမဟုတ် နေရာအမျိုးမျိုးက ပိုမြန်တဲ့ access အတွက် သုံးသည်။
Vector Database	embedding များကို သိမ်းပြီး အနီးစပ်ဆုံးဆင်တူတာများကို မြန်မြန်ရှာဖွေပေးဖို့ optimize လုပ်ထားတဲ့ database — semantic search နဲ့ AI application များအတွက် အသုံးများသည်။
Embedding	data (text, image စသည်) ကို ဆင်တူတဲ့ item တွေ vector space ထဲမှာ အနီးကပ်ရောက်နေအောင် ဖော်ပြထားတဲ့ numeric vector representation။

Database Product Decision Guide

လိုအပ်ချက်	ရွေးချယ်သင့်သည်
Need a general-purpose relational web database	PostgreSQL (သို့) MySQL တို့ ကိုက်ညီနိုင်ပါတယ် — နှစ်ခုစလုံးက web application အများစုနဲ့ ကိုက်ညီတဲ့ mature relational database တွေဖြစ်ပါတယ်။
Need embedded/local relational storage	SQLite ကိုက်ညီနိုင်ပါတယ် — application ထဲမှာ file တစ်ခုတည်းအနေနဲ့ run ပြီး သီးခြား server စီမံစရာမလိုပါ။
Need document-oriented, flexible data	MongoDB ကိုက်ညီနိုင်ပါတယ် — ပုံစံပြောင်းလဲနေတတ်တဲ့ data အတွက် ကိုက်ညီတဲ့ JSON-like document flexible ကို သိမ်းပေးသည်။
Need a fast cache, session store, or key-value store	Redis ကိုက်ညီနိုင်ပါတယ် — read/write အလွန်မြန်ဆန်ဖို့ တည်ဆောက်ထားတဲ့ in-memory key-value store တစ်ခုဖြစ်ပါတယ်။
Need managed PostgreSQL with built-in auth/storage	Supabase ကိုက်ညီနိုင်ပါတယ် — managed PostgreSQL ကို authentication နဲ့ file storage တွဲပေးထားသည် (အသေးစိတ်ကို Cloud Providers & Platforms course တွင် ကြည့်ပါ)။
Need complex relational queries across many entities	entity များစွာအပေါ် ရှုပ်ထွေးတဲ့ query များအတွက် index ကောင်းကောင်း ဒီဇိုင်းလုပ်ထားတဲ့ relational database ကနေ စတင်လေ့ရှိပါတယ်။
Need real-time, flexible writes at scale	write load အလွန်မြင့်ပြီး ပုံစံအမျိုးမျိုးရှိတဲ့အခါ document (သို့) wide-column NoSQL store က strict relational schema ထက် ပိုကိုက်ညီနိုင်ပါတယ်။
Need semantic/similarity search for AI	vector database တစ်ခုကို application ရဲ့ ကျန်တဲ့ data များအတွက် relational database တစ်ခုနဲ့ တွဲသုံးလေ့ရှိပါတယ်။
Unsure where to start	PostgreSQL ကဲ့သို့ general-purpose relational database တစ်ခုက application အသစ်အများစုအတွက် သင့်လျော်တဲ့ default ဖြစ်ပါတယ်။