Thuta Learning
How Databases Work
ProjectsData & Databasesbeginner

ပရောဂျက် - မှန်ကန်သော Database ကို ရွေးချယ်ခြင်း

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • ပရောဂျက် - မှန်ကန်သော Database ကို ရွေးချယ်ခြင်း concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram/table ကို ဖတ်ပြီး data model/schema/architecture ဘယ်လို ပုံသဏ္ဌာန်ရှိသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် project အတွက် database concept/system ကို ဘယ်လို အသုံးချသင့်သလဲ ရှင်းပြနိုင်ရန်

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

ဒါက capstone project ဖြစ်ပြီး schema တစ်ခုမှ ရေးဆွဲစေခြင်းမရှိပါဘူး - သင်ရိုးထဲက ဆုံးဖြတ်ချက်ချသည့်ဘက်ကို ကျင့်သုံးစေပါတယ်။

  • SQL-vs-NoSQL - tradeoff များ
  • Database-systems-landscape - category တစ်ခုစီ ဘာအတွက်ကောင်းလဲ
  • SQLite - embedded engine သေးငယ်တစ်ခုရဲ့ case
  • Vector databases - embedding များ သိမ်းဆည်းခြင်း

Author, post, comment, tag ပါတဲ့ blog တစ်ခုက multi-table join နှင့် referential integrity လိုအပ်ပါတယ် - relational database ရဲ့ အားသာချက်အတိုင်းပါပဲ။

Real-time chat app တစ်ခုက release တစ်ခုချင်းစီမှာ ပုံသဏ္ဍာန်ပြောင်းနေတဲ့ message တွေကို မြန်ဆန်စွာ ရေးရမှာဖြစ်ပါတယ် - document database ရဲ့ flexible-write case ပါပဲ။

Cache/session layer တစ်ခုက relationship လိုအပ်ချက်မရှိဘဲ အလွန်မြန်ဆန်တဲ့ key lookup တစ်ခုတည်း လိုအပ်ပါတယ် - key-value store ကို သီးခြား category ပေးထားရတဲ့ အကြောင်းရင်းပါပဲ။

RAG application တစ်ခုက ပုံမှန် application data နှင့် embedding များအပေါ် similarity search နှစ်ခုစလုံး လိုအပ်ပါတယ် - vector index တစ်ခုကို ပုံမှန် store နှင့်အတူ လိုအပ်ပါတယ်။

Type အရင် Product နောက်

Category မှန်ကန်တာကို နာမည်တပ်ပြီး ဘာကြောင့်ဆိုတာ ရှင်းပြနိုင်ခြင်းဟာ ဒီသင်ရိုးတစ်ခုလုံးက တည်ဆောက်ပေးလာခဲ့တဲ့ တကယ့် skill ဖြစ်ပါတယ်။

text
CHOOSE THE RIGHT DATABASE
-------------------------
CHOOSE THE RIGHT DATABASE
-------------------------
SCENARIO                           RECOMMENDED TYPE
--------------------------------------------------------
Blog: authors/posts/comments/tags   -> Relational (SQL)
  needs multi-table JOINs, integrity

Chat app: fast, evolving messages   -> Document (NoSQL)
  needs flexible schema, high writes

Cache / session layer               -> Key-Value store
  needs simple, very fast lookups

RAG app: app data + embeddings      -> Relational/Document
                                        + Vector database
  needs similarity search on top of normal data

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

Database type တစ်ခု နာမည်မတပ်မီ scenario တစ်ခုစီအတွက် တူညီတဲ့ မေးခွန်းကို မေးပါ - ဒီ data အပေါ် ပုံမှန် query တစ်ခုက တကယ်ဘာလုပ်ပေးရမှာလဲ။

ScenarioAccess pattern က ဘာလိုအပ်လဲ
Content-heavy blogAuthor/post/comment/tag ကို join လုပ်ပြီး integrity ကောင်းရမည် -> Relational (SQL) database
Real-time chat appပုံသဏ္ဍာန်ပြောင်းနေသော message ကို မြန်ဆန်စွာ write လုပ်ရမည် -> Document database (NoSQL)
Cache / session layerRelationship မလိုဘဲ အလွန်မြန်သော key lookup သာလိုအပ် -> Key-value store
RAG applicationပုံမှန် app data နှင့် embedding အပေါ် similarity search နှစ်ခုလုံးလိုအပ် -> Relational/Document + Vector database

Dominant need ကို ဖော်ထုတ်ပါ

Scenario တစ်ခုစီအတွက် အရေးအကြီးဆုံး access pattern ကို ရှာပါ - relations, flexible writes, cache, ဒါမှမဟုတ် vector search။

သင်ခန်းစာနှင့် ကိုက်ညှိပါ

Need တစ်ခုစီကို ၎င်းကို ရှင်းပြခဲ့တဲ့ သင်ခန်းစာနှင့် ချိတ်ဆက်ပါ - SQL-vs-NoSQL, landscape, ဒါမှမဟုတ် vector database။

Type ကို ရွေးပါ

Product အမည်မဟုတ်ဘဲ category (relational, document, key-value, vector) ကို ရွေးပါ။

ဝါကျတစ်ကြောင်းနှင့် ခိုင်လုံအောင် ရှင်းပြပါ

Scenario ဘာကြောင့် ဒီ type လိုအပ်လဲကို ဝါကျတစ်ကြောင်းတည်းနှင့် ရေးပါ။

ဝါကျတစ်ကြောင်းနှင့် ဖော်ပြနိုင်ရမည်

Scenario က database type တစ်ခုကို ဘာကြောင့် လိုအပ်လဲဆိုတာ ဖော်ပြနိုင်မှသာ ရွေးချယ်မှု ပြီးဆုံးသည်ဟု ဆိုနိုင်သည်။

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

javascript
function chooseDatabaseType(scenario) {
  if (scenario.needsVectorSearch) {
    return {
      type: "Relational/document store + vector database (e.g. Postgres + pgvector)",
      reason: "app data needs relations, but similarity search over embeddings needs a vector index alongside it"
    };
  }
  if (scenario.needsComplexRelations) {
    return {
      type: "Relational (SQL) database",
      reason: "joins across authors, posts, comments, and tags need referential integrity and multi-table JOINs"
    };
  }
  if (scenario.needsSimpleKeyValueCache) {
    return {
      type: "Key-value store (e.g. Redis)",
      reason: "sub-millisecond reads/writes on simple key lookups matter more than relationships"
    };
  }
  if (scenario.needsFlexibleFastWrites) {
    return {
      type: "Document database (NoSQL)",
      reason: "flexible, fast-changing message shape and high write throughput fit a schema-less document model"
    };
  }
  return {
    type: "Relational (SQL) database",
    reason: "default to SQL when no specialized access pattern dominates"
  };
}

const scenarios = {
  blog: {
    needsComplexRelations: true,
    needsFlexibleFastWrites: false,
    needsSimpleKeyValueCache: false,
    needsVectorSearch: false
  },
  chat: {
    needsComplexRelations: false,
    needsFlexibleFastWrites: true,
    needsSimpleKeyValueCache: false,
    needsVectorSearch: false
  },
  cache: {
    needsComplexRelations: false,
    needsFlexibleFastWrites: false,
    needsSimpleKeyValueCache: true,
    needsVectorSearch: false
  },
  rag: {
    needsComplexRelations: false,
    needsFlexibleFastWrites: false,
    needsSimpleKeyValueCache: false,
    needsVectorSearch: true
  }
};

Object.entries(scenarios).forEach(([name, s]) => {
  const result = chooseDatabaseType(s);
  console.log(`${name}: ${result.type}\n  -> ${result.reason}`);
});
You should see
blog: Relational (SQL) database
  -> joins across authors, posts, comments, and tags need referential integrity and multi-table JOINs
chat: Document database (NoSQL)
  -> flexible, fast-changing message shape and high write throughput fit a schema-less document model
cache: Key-value store (e.g. Redis)
  -> sub-millisecond reads/writes on simple key lookups matter more than relationships
rag: Relational/document store + vector database (e.g. Postgres + pgvector)
  -> app data needs relations, but similarity search over embeddings needs a vector index alongside it

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

ပဉ္စမ scenario တစ်ခု - multiplayer game ၏ live leaderboard အတွက် သေးငယ်ပြီး မကြာခဏ update ဖြစ်သော ranked list ကို sub-millisecond ဖတ်ရှုနိုင်ရမည်။ chooseDatabaseType ထဲသို့ needsRankedFastReads flag တစ်ခု ထပ်ထည့်ပြီး ရှိပြီးသား branch ထဲ ထည့်သင့်သလား ဒါမှမဟုတ် branch အသစ်တစ်ခု လိုအပ်သလား ဆုံးဖြတ်ပါ။

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

Scenario တစ်ခုက တကယ်လိုအပ်တဲ့ database type ကို မဆုံးဖြတ်မီ ထုတ်ကုန်အမည် (ဥပမာ 'MongoDB') ကို အရင်ရွေးချယ်ခြင်း - type ကသာ product ရွေးချယ်မှုကို ဦးဆောင်သင့်ပြီး ပြောင်းပြန်မဟုတ်ပါ

Real system တစ်ခု (RAG app ကဲ့သို့) သည် database type နှစ်ခု အတူတကွ လိုအပ်နေချိန်တွင် dominant need တစ်ခုတည်းသာ ရှိသည်ဟု မှားယွင်းစွာ ယူဆခြင်း

Pinecone: What Is a Vector Database?How Databases Work

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • Scenario တစ်ခုက တကယ်လိုအပ်တဲ့ database type ကို မဆုံးဖြတ်မီ ထုတ်ကုန်အမည် (ဥပမာ 'MongoDB') ကို အရင်ရွေးချယ်ခြင်း - type ကသာ product ရွေးချယ်မှုကို ဦးဆောင်သင့်ပြီး ပြောင်းပြန်မဟုတ်ပါ
  • Real system တစ်ခု (RAG app ကဲ့သို့) သည် database type နှစ်ခု အတူတကွ လိုအပ်နေချိန်တွင် dominant need တစ်ခုတည်းသာ ရှိသည်ဟု မှားယွင်းစွာ ယူဆခြင်း
  • ဒီ course က database concept/landscape ကို framework-neutral level မှာသာ သင်ပေးပါတယ် — SQL syntax, PostgreSQL, MongoDB, Redis ကို နက်နက်ရှိုင်းရှိုင်း လေ့လာချင်ရင် SQL, PostgreSQL, MongoDB, Redis tutorial တွေဆီ ဆက်သွားပါ။

လေ့ကျင့်ခန်း

ပဉ္စမ scenario တစ်ခု - multiplayer game ၏ live leaderboard အတွက် သေးငယ်ပြီး မကြာခဏ update ဖြစ်သော ranked list ကို sub-millisecond ဖတ်ရှုနိုင်ရမည်။ chooseDatabaseType ထဲသို့ needsRankedFastReads flag တစ်ခု ထပ်ထည့်ပြီး ရှိပြီးသား branch ထဲ ထည့်သင့်သလား ဒါမှမဟုတ် branch အသစ်တစ်ခု လိုအပ်သလား ဆုံးဖြတ်ပါ။

You'll know it worked when: blog: Relational (SQL) database -> joins across authors, posts, comments, and tags need referential integrity and multi-table JOINs chat: Document database (NoSQL) -> flexible, fast-changing message shape and high write throughput fit a schema-less document model cache: Key-value store (e.g. Redis) -> sub-millisecond reads/writes on simple key lookups matter more than relationships rag: Relational/document store + vector database (e.g. Postgres + pgvector) -> app data needs relations, but similarity search over embeddings needs a vector index alongside it