Мэдээллийн сан гэж юу вэ? Аппаа бүтээгчдэд зориулсан гарын авлага
Мэдээллийн сан бол апп хадгалж, уншдаг зохион байгуулалттай мэдээллийн сан юм: түүний хэрэглэгчид, захиалгууд, цаг товлолтууд, мессежүүд. Хөтчийн таб дээр хадгалагдсан мэдээллээс ялгаатай нь мэдээллийн сан дахь өгөгдөл шинэчлэх эсвэл дахин эхлүүлсний дараа ч хэвээр байж, апп ашиглагч бүр ижил бүртгэлийг харна. Ихэнх мэдээллийн сан өгөгдлийг хүснэгтэд зохион байгуулдаг; энэ нь хүснэгтийн программ шиг боловч өгөгдлийг тогтвортой байлгах хатуу дүрмүүдтэй.
AI-аар бүтээхдээ яагаад чухал вэ
AI-аар бүтээгчдийн хамгийн түгээмэл гайхшрал бол апп бүрэн бэлэн мэт харагдаад бүх зүйлээ мартдаг явдал юм. Та хэрэглэгч нэмээд хуудсыг шинэчилбэл тэр нь алга болдог. Энэ нь ихэвчлэн апп өгөгдлийг мэдээллийн сан биш, хөтчийн санах ойд хадгалсан байдгийн шинж юм.
Мэдээллийн сан бол таны хамгийн чухал шийдвэрүүдийн хаана амьдардаг газар юм, танд мэдэгдэх эсэхээс үл хамааран:
- Юуг бүртгэх вэ. Захиалгын статусыг хадгалаагүй бол цуцлагдсан захиалгуудыг харуулах боломжгүй.
- Юу хэрхэн холбогдох вэ. Нэг үйлчлүүлэгч олон захиалгатай эсэх, эсвэл нэг захиалга олон үйлчилгээтэй эсэх нь бүх аппын загварыг тодорхойлдог.
- Хэн юуг харж болох вэ. Нууцлалын ихэнх алдаа нь хэрэглэгч аль бүртгэлийг унших эрхтэйг буруу тохируулахаас үүсдэг.
Та мэдээллийн санг өөрөө загварчлах шаардлагагүй. Гэхдээ үндсэн ойлголтыг ойлгох нь өгөгдлөө тодорхой тайлбарлаж, асуудлыг эрт олоход тусална.
Өдөр тутмын зүйрлэл
Жижиг оффисын сайн зохион байгуулсан файлын шүүгээг төсөөлөөд үз.
Шүүгээний сарни бүр нэг төрлийн зүйлийг хадгална: нэг сарни үйлчлүүлэгчид, нэг нь цаг товлолтууд, нэг нь нэхэмжлэхүүд. Сарни доторх хавтас бүр адил хэлбэртэй, адил талбаруудыг бөглөсөн байдаг. Хавтас бүр өвөрмөц лавлагааны дугаартай, нэхэмжлэх нь үйлчлүүлэгчтэй холбогдох үед нэхэмжлэхийн хавтас тэр үйлчлүүлэгчийн дугаарыг тэмдэглэдэг, бүтэн файлыг нь хуулдаггүй.
Энэ бол relational мэдээллийн сан. Сарниуд нь хүснэгт, хавтаснууд нь мөр, талбарууд нь багана, лавлагааны дугаарууд нь primary key, өөр хавтас руу заасан тэмдэглэл нь foreign key. Сайн оффисын менежер дүрэм мөрддөг: огноогүй цаг товлол байхгүй, ижил дугаартай хоёр үйлчлүүлэгч байхгүй, мөн мэдээллийн сан ч мөн адил.
Жишээ: үсчний захиалгын апп
Та AI-аас үсчний салонд зориулсан захиалгын сайт бүтээхийг хүсэж байна гэж бодъё. Ийм мэдээллийн сан дөрвөн хүснэгттэй байна.
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | Үс засалт | 45 | 40.00 |
| 2 | Будалт | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | Сара | sara@example.com |
| 2 | Омар | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | Лена Парк | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
bookings хүснэгтийг хараарай. Энэ нь Лена-гийн нэр, утасны дугаарыг захиалга бүрт хуулдаггүй; customer_id = 101 гэж хадгалдаг. Хэрэв Лена утасны дугаараа солиход нэг газар өөрчлөгдөж, захиалга бүр шинэ дугаарыг харуулна. Энэ бол relational мэдээллийн сангийн гол санаа: баримт бүрийг нэг удаа хадгалж, холбоосоор заа.
Ижил бүтэц нь хэрэгтэй асуултанд хариулна:
- "Омар баасан гарагт ямар цаг чөлөөтэй вэ?" — тэр өдрийн Омарын захиалгуудыг шалга.
- "Энэ сарын будалтын орлого хэд вэ?" — bookings-ийг services-тэй холбож, үнийг нь нэм.
- "90 хоногт ороогүй үйлчлүүлэгчид хэн бэ?" — customers-ийг сүүлчийн захиалгатай нь харьцуул.
Гол нэр томьёо
| Нэр томьёо | Утга |
|---|---|
| Хүснэгт (table) | Нэг төрлийн бүртгэлийн цуглуулга, жишээлбэл үйлчлүүлэгчид эсвэл захиалгууд. |
| Мөр (row / record) | Хүснэгтийн нэг зүйл, нэг үйлчлүүлэгч, нэг захиалга. |
| Багана (column / field) | Мөр бүрт байх мэдээллийн нэг хэсэг, жишээлбэл имэйл эсвэл үнэ. |
| Primary key | Мөр бүрийн өвөрмөц ID, ихэвчлэн дугаар эсвэл санамсаргүй мөр. |
| Foreign key | Өөр хүснэгтийн мөр рүү заадаг багана, жишээлбэл bookings дахь customer_id. |
| Schema | Ерөнхий загвар: ямар хүснэгтүүд байгаа, тэдгээрийн багана, холбогдох байдал. |
| Query | Өгөгдөл унших эсвэл өөрчлөх хүсэлт, жишээлбэл "маргаашийн бүх захиалга." |
| SQL | Structured Query Language, relational мэдээллийн санд асуулга хийх стандарт хэл. |
| Migration | Schema-д хийсэн хадгалагдсан, давтагдах өөрчлөлт, жишээлбэл багана нэмэх. |
| Index | Багана дээрх хайлтыг хурдасгадаг хайлтын бүтэц, номын индекс шиг. |
| CRUD | Create, Read, Update, Delete: аппууд өгөгдөлтэй хийдэг дөрвөн үндсэн үйлдэл. |
| Нөөцлөлт (backup) | Алдаа гарвал сэргээж болох өгөгдлийн хуулбар. |
Мэдээллийн сангийн төрлүүд
| Төрөл | Өгөгдлийг хэрхэн хадгалдаг | Жишээ | Тохиромжтой |
|---|---|---|---|
| Relational (SQL) | Тогтмол баганатай, хоорондоо холбогдсон хүснэгтүүд | Postgres, MySQL, SQLite | Ихэнх бизнесийн апп: захиалга, дэлгүүр, CRM, SaaS |
| Document (NoSQL) | Уян хатан JSON төстэй баримтууд | MongoDB, Firestore | Бүртгэл бүрийн хэлбэр ихээр ялгаатай өгөгдөл |
| Key-value | Түлхүүр дор хадгалсан утга | Redis | Кэш, session зэрэг богино хугацааны өгөгдөл |
Бизнес эсвэл жижиг байгууллага эхлээд бүтээх ихэнх зүйлд relational мэдээллийн сан бол найдвартай анхдагч сонголт.
Мэдээллийн сан аппын хаана байдаг вэ
Зочид мэдээллийн санд шууд ханддаггүй. Тэдний хөтөч дэх хуудас (frontend) серверээс (backend) өгөгдөл хүсдэг, ихэвчлэн API-ээр дамжина. Сервер хэн асууж байгааг шалгаж, зөвшөөрөгдсөн эсэхийг шалгаад мэдээллийн санд асуулга хийж, тэр хүнд харагдах ёстой зүйлийг л буцаана.
Энэ дунд алхам чухал. Хэрэв хөтөч мэдээллийн санд бүх эрхтэйгээр шууд асуулга хийж чадвал хэн ч developer tools нээж бүх зүйлийг унших боломжтой болно.
Түгээмэл алдаа, буруу ойлголт
- Өгөгдлөө зөвхөн хөтөчид хадгалах. Хөтчийн санах ой (localStorage гэх мэт) нэг төхөөрөмж, нэг хөтөчид л байдаг. Сүүлд үзсэн шүүлтүүрт зориулагдсан ч захиалгад тохирохгүй.
- Бүх зүйлийг нэг хүснэгтэд хийх. Захиалгын хүснэгтэд үйлчлүүлэгчийн нэр, утас, үйлчилгээний үнийг мөр бүрт хуулбарлавал хурдан зөрчилдөнө.
- Нууц үгийг энгийн текстээр хадгалах. Нууц үгийг hash хийж, хэзээ ч уншигдахаар хадгалах ёсгүй. Нэвтрэлт гэж юу вэ-ыг үзнэ үү.
- Өгөгдөлд дүрэм байхгүй. Шаардлагатай талбар, давтагдашгүй утгын дүрэмгүй бол огноогүй захиалга, давхардсан үйлчлүүлэгч гарна.
- Устгахыг бодохгүй байх. Үйлчлүүлэгчийг устгахад түүний захиалгуудыг устгах уу, хадгалах уу, эсвэл хориглох уу гэдгээ шийд.
- Продакшний өгөгдөл дээр туршилт хийх. Эрсдэлтэй өөрчлөлтийг эхлээд аюулгүй газар туршиж, нөөцлөлтөө хадгал.
- Хүснэгтийг үүрд мэдээллийн сан гэж бодох. Хүснэгт эхлэхэд сайн ч олон хүн нэгэн зэрэг ашиглах, эрхийн удирдлагад хүнд байдаг. Хүснэгтийг аппад хэрхэн хөрвүүлэх вэ-ыг үзнэ үү.
AI бүтээгчээсээ юу гуйх вэ
- "Үүнийг хөтөчид биш, мэдээллийн санд хадгал. Ямар хүснэгт үүсгэхээ надад хэл."
- "Schema-г энгийн хүснэгтээр харуул: хүснэгт бүр, түүний багана, холбогдох байдал."
- "Үйлчлүүлэгч олон захиалгатай байж болно; захиалга бүр яг нэг үйлчилгээ, нэг ажилтантай байна."
- "Үйлчлүүлэгчийн имэйлийг заавал оруулах бөгөөд давтагдахгүй байлга."
- "Нэг ажилтны хоёр захиалга давхцахгүй байхыг зогсоо."
- "Зөвхөн нэвтэрсэн эзэн бүх захиалгыг унших боломжтой; үйлчлүүлэгчид зөвхөн өөрийнхөө захиалгыг харна. Үүнийг серверт мөрдүүл."
- "Би үйлчилгээг устгахад өмнөх захиалгуудыг бүү устга, харин үйлчилгээг идэвхгүй гэж тэмдэглэ."
Mythex дээрх мэдээллийн сан
Таны апп өгөгдөл хадгалах шаардлагатай үед Mythex төсөлд зориулсан Postgres мэдээллийн сан нэмдэг. Чатад асууж ("хүлээлтийн жагсаалтын бүртгэлийг мэдээллийн санд хадгал") эсвэл /database командыг ашиглаж болно. Холболтын мэдээлэл аппд автоматаар дамжиж, агент хүснэгтүүдийг үүсгэдэг. Мэдээллийн сан таван минут идэвхгүй байвал унтаж, дараагийн хүсэлтээр сэрдэг; нийтлэгдсэн хэрэглээг сэрсэн хугацаагаар нь, бүтээх үеийн кредит балансаас тооцно. Free ба Pro дээр боломжтой. Дэлгэрэнгүйг мэдээллийн сангийн баримт-аас, мөн эхлэх өгөгдөлтэй загваруудыг аппын загварууд-аас үзнэ үү.
Асуултууд
Мэдээллийн сан гэж юу вэ, энгийнээр хэлбэл?
Мэдээллийн сан бол апп хадгалж, уншдаг зохион байгуулалттай мэдээллийн сан юм, жишээлбэл хэрэглэгчид, захиалга эсвэл захиалгууд. Хөтчийн таб дээр л хадгалагдсан өгөгдлөөс ялгаатай нь шинэчлэх, дахин эхлүүлэх эсвэл өөр төхөөрөмжөөс нээх үед ч хадгалагдсан хэвээр байна.
Хүснэгт бол мэдээллийн сан уу?
Хүснэгт ижил төрлийн мэдээллийг хадгалж чадах ч апп зориулагдаагүй. Жинхэнэ мэдээллийн сан баганад юу хадгалахыг хязгаарлах дүрмийг мөрдүүлж, хүснэгтүүдийг найдвартай холбож, олон хүн зэрэг бичих боломжийг бүрдүүлж, хэн юуг унших эрхтэйг хянадаг.
SQL ба NoSQL мэдээллийн сангийн ялгаа юу вэ?
SQL (relational) мэдээллийн сан, жишээлбэл Postgres болон MySQL, өгөгдлийг тодорхой баганатай хүснэгтээр болон хүснэгтүүдийн хоорондын холбоосоор хадгална. NoSQL, жишээлбэл MongoDB, илүү уян хатан баримт хадгална. Ихэнх бизнесийн апп, захиалга, CRM, дэлгүүр нь relational загварт сайн тохирдог.
Аппдаа мэдээллийн сан хэрэгтэй юу?
Хэрэв апп нь хэрэглэгчийн оруулсан бүртгэл, захиалга, мессеж, тохиргоо зэрэг аливаа зүйлийг санах, дараа нь эсвэл өөр хүнд харуулах шаардлагатай бол тийм. Зөвхөн мэдээлэл харуулдаг, өгөгдөл хадгалдаггүй маягт бүхий вэбсайтад ихэвчлэн хэрэггүй.