Ի՞նչ է տվյալների բազան. ուղեցույց հավելվածներ կառուցողների համար
Տվյալների բազան կազմակերպված տեղեկատվության պահոց է, որում հավելվածը պահում և կարդում է տվյալներ՝ իր օգտատերերին, պատվերները, ամրագրումները, հաղորդագրությունները։ Ի տարբերություն միայն բրաուզերում պահվող տվյալների, տվյալների բազայում գրվածը մնում է էջը թարմացնելուց կամ սերվերը վերագործարկելուց հետո, և հավելվածն օգտագործող բոլորն էլ տեսնում են նույն գրառումները։ Տվյալների մեծ մասը տվյալների բազաներում կազմակերպվում է աղյուսակների տեսքով, շատ նման թերթերի աղյուսակի, բայց խիստ կանոններով, որոնք պահում են տվյալների հետևողականությունը։
Ինչու է դա կարևոր AI-ով կառուցելիս
AI-ով կառուցողների համար ամենատարածված անակնկալը հավելվածն է, որը պատրաստ է թվում, բայց ամեն ինչ մոռանում է։ Ավելացնում եք հաճախորդ, թարմացնում էջը, և նա վերացել է։ Սովորաբար դա նշանակում է, որ հավելվածը տվյալները պահում էր բրաուզերի հիշողության մեջ, ոչ թե տվյալների բազայում։
Տվյալների բազան նաև այն տեղն է, որտեղ են ձեր շատ կարևոր որոշումները, անկախ նրանից, գիտակցում եք դա, թե ոչ․
- Ինչ եք գրանցում։ Եթե ամրագրման կարգավիճակը չեք պահում, չեք կարող ցույց տալ, թե որ ամրագրումներն են չեղարկվել։
- Ինչպես են բաները կապված։ Արդյոք մեկ հաճախորդը կարող է ունենալ բազմաթիվ ամրագրումներ, թե մեկ ամրագրումը՝ բազմաթիվ ծառայություններ, ձևավորում է ամբողջ հավելվածը։
- Ով ինչ կարող է տեսնել։ Գաղտնիության սխալների մեծ մասը վերաբերում է այն բանին, թե որ գրառումները կարող է կարդալ օգտատերը։
Տվյալների բազան ինքներդ նախագծելու կարիք չունեք։ Բայց հիմունքների իմացությունը թույլ է տալիս հստակ նկարագրել ձեր տվյալները և վաղ բացահայտել խնդիրները։
Ամենօրյա անալոգիա
Պատկերացրեք լավ կազմակերպված թղթապանակների պահարան փոքր գրասենյակում։
Յուրաքանչյուր դարակ պահում է մի տեսակի բան՝ մեկը հաճախորդների, մյուսը՝ ժամադրությունների, երրորդը՝ հաշիվների։ Յուրաքանչյուր դարակի ներսում յուրաքանչյուր թղթապանակ նույն ձևաչափին է հետևում, նույն դաշտերը լրացված։ Յուրաքանչյուր թղթապանակ ունի եզակի հղման համար, և երբ հաշիվը պատկանում է հաճախորդի, հաշվի թղթապանակը նշում է այդ հաճախորդի համարը՝ նրա ամբողջ ֆայլը պատճենելու փոխարեն։
Այս է հարաբերական տվյալների բազան։ Դարակները աղյուսակներ են, թղթապանակները՝ տողեր, դաշտերը՝ սյունակներ, հղման համարները՝ 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։ Եթե Լենան փոխի հեռախոսահամարը, այն փոխվում է մեկ տեղում, և յուրաքանչյուր ամրագրում ցույց է տալիս նորը։ Սա հարաբերական տվյալների բազայի հիմնական գաղափարն է․ յուրաքանչյուր փաստ պահել մեկ անգամ և կապել դրան։
Նույն կառուցվածքը պատասխանում է օգտակար հարցերի․
- «Ո՞ր ժամերն են ազատ Օմարի համար ուրբաթ օրը» — նայեք Օմարի այդ օրվա ամրագրումներին։
- «Որքան եկամուտ բերեցին ներկումները այս ամիս» — միացրեք ամրագրումները ծառայություններին և գումարեք գները։
- «Ո՞ր հաճախորդները 90 օրվա ընթացքում չեն ամրագրել» — համեմատեք հաճախորդներին նրանց վերջին ամրագրման հետ։
Հիմնական տերմինների բացատրություն
| Տերմին | Ինչ է նշանակում |
|---|---|
| Աղյուսակ (Table) | Մի տեսակի գրառումների հավաքածու, օրինակ՝ հաճախորդներ կամ ամրագրումներ։ |
| Տող (Row, record) | Աղյուսակի մեկ նյութ՝ մեկ հաճախորդ, մեկ ամրագրում։ |
| Սյունակ (Column, field) | Տեղեկատվության մի մաս, որ յուրաքանչյուր տող ունի, օրինակ՝ էլ․ փոստ կամ գին։ |
| Primary key | Յուրաքանչյուր տողի եզակի ID, սովորաբար թիվ կամ պատահական տող։ |
| Foreign key | Սյունակ, որը մեկ այլ աղյուսակի տողին է ցույց տալիս, օրինակ՝ customer_id-ն ամրագրումներում։ |
| Սխեմա (Schema) | Ընդհանուր նախագիծը․ ինչ աղյուսակներ կան, նրանց սյունակները և ինչպես են կապվում։ |
| Հարցում (Query) | Հարցում տվյալները կարդալու կամ փոխելու համար, օրինակ՝ «վաղվա բոլոր ամրագրումները»։ |
| SQL | Structured Query Language, հարաբերական տվյալների բազաների ստանդարտ լեզուն։ |
| Միգրացիա (Migration) | Սխեմայի պահված, կրկնվող փոփոխություն, օրինակ՝ սյունակ ավելացնելը։ |
| Ինդեքս (Index) | Որոնման կառուցվածք, որը արագացնում է սյունակի որոնումները, ինչպես գրքի ինդեքսը։ |
| CRUD | Create, Read, Update, Delete՝ չորս հիմնական գործողությունները, որ հավելվածները կատարում են տվյալների հետ։ |
| Պահուստային պատճեն (Backup) | Տվյալների պատճենը, որ կարող եք վերականգնել, եթե ինչ-որ բան սխալ լինի։ |
Տվյալների բազաների տեսակները
| Տեսակ | Ինչպես է պահում տվյալները | Օրինակներ | Լավ է համար |
|---|---|---|---|
| Հարաբերական (SQL) | Աղյուսակներ՝ ֆիքսված սյունակներով և նրանց միջև կապերով | Postgres, MySQL, SQLite | Բիզնես հավելվածների մեծ մասը՝ ամրագրումներ, խանութներ, CRM, SaaS |
| Փաստաթղթային (NoSQL) | Ճկուն, JSON-ի նման փաստաթղթեր | MongoDB, Firestore | Տվյալներ, որոնց ձևը մեծապես տարբերվում է գրառումից գրառում |
| Բանալի-արժեք (Key-value) | Արժեք՝ բանալիի տակ | Redis | Քեշավորում, կարճատև տվյալներ, ինչպես սեսիաները |
Գրեթե այն ամենի համար, ինչ հիմնադիրը կամ փոքր բիզնեսը նախ կառուցում է, հարաբերական տվյալների բազան անվտանգ լռելյայն ընտրությունն է։
Որտեղ է տվյալների բազան ձեր հավելվածում
Այցելուները երբեք ուղղակիորեն չեն խոսում տվյալների բազայի հետ։ Նրանց բրաուզերի էջը (ճակատային մասը՝ frontend) տվյալներ է խնդրում ձեր սերվերից (backend)՝ սովորաբար API-ի միջոցով։ Սերվերը ստուգում է, թե ով է հարցնում և թույլատրվա՞ծ է արդյոք, այնուհետև հարցում է տվյալների բազային և ուղարկում միայն այն, ինչ այդ անձը պետք է տեսնի։
Այդ միջանկյալ քայլը կարևոր է։ Եթե բրաուզերը կարողանար ուղղակիորեն հարցում անել տվյալների բազային լիարժեք մուտքով, ցանկացած մարդ կարող էր բացել մշակողական գործիքները և կարդալ ամեն ինչ։
Տարածված սխալներ և թյուրըմբռնումներ
- Տվյալները պահել միայն բրաուզերում։ Բրաուզերի պահոցը (ինչպես localStorage-ը) գտնվում է մեկ սարքի և մեկ բրաուզերի վրա։ Դա լավ է հիշված ֆիլտրի համար, բայց ոչ պատվերների։
- Ամեն ինչ մեկ աղյուսակում դնելը։ Մեկ «ամրագրումների» աղյուսակ, որտեղ յուրաքանչյուր տողում պատճենված է հաճախորդի անունը, հեռախոսը և ծառայության գինը, արագ անհամաձայնության մեջ է մտնում։
- Գաղտնաբառերը սովորական տեքստով պահելը։ Գաղտնաբառերը պետք է հեշավորվեն, երբեք կարդալի տեսքով չպահվեն։ Տե՛ս ինչ է նույնականացումը։
- Տվյալների վրա կանոնների բացակայությունը։ Առանց պարտադիր դաշտերի և եզակիության կանոնների կստանաք ամրագրումներ առանց ամսաթվի և կրկնվող հաճախորդներ։
- Ջնջելը մոռանալը։ Որոշեք՝ հաճախորդին ջնջելը ջնջի՞ նրա ամրագրումները, պահի՞ դրանք, թե արգելվի։
- Արտադրական տվյալները փորձերի համար օգտագործելը։ Վտանգավոր փոփոխությունները նախ փորձարկեք անվտանգ տեղում և պահեք պահուստային պատճեններ։
- Աղյուսակը ընդմիշտ տվյալների բազա համարելը։ Աղյուսակները հիանալի են սկսելու համար, բայց դժվարանում են մի քանի օգտատերերի և թույլտվությունների հետ միաժամանակ աշխատելիս։ Տե՛ս ինչպես աղյուսակը դարձնել հավելված։
Ինչ խնդրել AI կառուցիչից
- «Պահիր սա տվյալների բազայում, ոչ թե բրաուզերում։ Ասա, թե ո՛ր աղյուսակները կստեղծես։»
- «Ցույց տուր սխեման որպես պարզ աղյուսակ՝ յուրաքանչյուր աղյուսակ, նրա սյունակները և ինչպես են կապվում։»
- «Հաճախորդը կարող է ունենալ բազմաթիվ ամրագրումներ, և յուրաքանչյուր ամրագրում ունի ճիշտ մեկ ծառայություն և մեկ աշխատակից։»
- «Հաճախորդի համար email-ը պարտադիր և եզակի դարձրու։»
- «Կանգնեցրու երկու ամրագրումները նույն աշխատակցի համար համընկնելը։»
- «Ամբողջ ամրագրումները կարող է տեսնել միայն մուտք գործած սեփականատերը, հաճախորդները՝ միայն իրենցը։ Պարտադրիր դա սերվերում։»
- «Երբ ջնջում եմ ծառայություն, անցյալի ամրագրումները չջնջես։ Նշիր ծառայությունը որպես ոչ ակտիվ։»
Տվյալների բազաներ Mythex-ում
Երբ ձեր հավելվածին տվյալներ պահել է պետք, Mythex-ը նախագծին ավելացնում է նվիրված Postgres տվյալների բազա։ Կարող եք խնդրել չատում («պահիր սպասման ցանկի գրանցումները տվյալների բազայում») կամ օգտագործել /database հրամանը։ Կապի տվյալները ավտոմատ կերպով փոխանցվում են ձեր հավելվածին, իսկ agent-ը ստեղծում է աղյուսակները։ Տվյալների բազան քնում է հինգ րոպե անգործության հետո և արթնանում հաջորդ հարցման ժամանակ, իսկ հրապարակված օգտագործումը վճարվում է այն ժամանակի համար, երբ այն արթուն է եղել, նույն կրեդիտի հաշվեկշռից, ինչ կառուցելը։ Հասանելի է Free և Pro պլաններում։ Տե՛ս տվյալների բազայի փաստաթղթերը, իսկ հավելվածների կաղապարները-ում կան տվյալների վրա հիմնված սկզբնական կետեր։
Հարցեր
Ի՞նչ է տվյալների բազան պարզ խոսքերով։
Տվյալների բազան կազմակերպված տեղեկատվության պահոց է, որում հավելվածը կարող է պահել և կարդալ տվյալներ, օրինակ՝ օգտատերերին, պատվերները կամ ամրագրումները։ Ի տարբերություն միայն բրաուզերի ներսում պահվող տվյալների, այն մնում է նույնիսկ էջը թարմացնելուց, սերվերը վերագործարկելուց կամ երբ հավելվածը բացում են այլ սարքից։
Աղյուսակը տվյալների բազա՞ է։
Աղյուսակը կարող է պահել նույն տեսակի տվյալները, բայց այն հավելվածների համար նախատեսված չէ։ Իրական տվյալների բազան պարտադրում է սյունակներում պահվող արժեքների կանոնները, հուսալիորեն կապում աղյուսակները, կարողանում է միաժամանակ շատ մարդկանց գրառումները կարգավորել և վերահսկում է, թե ով ինչ կարող է կարդալ։
Ո՞րն է SQL և NoSQL տվյալների բազաների տարբերությունը։
SQL (relational) տվյալների բազաները, ինչպիսիք են Postgres-ը և MySQL-ը, տվյալները պահում են աղյուսակներում՝ սահմանված սյունակներով և նրանց միջև կապերով։ NoSQL բազաները, ինչպիսին է MongoDB-ն, պահում են ավելի ճկուն փաստաթղթեր։ Բիզնես հավելվածների մեծ մասը՝ ամրագրումները, CRM-ները, խանութները, լավ է համապատասխանում հարաբերական մոդելին։
Իմ հավելվածին տվյալների բազա՞ն է պետք։
Եթե այն պետք է հիշի մարդկանց մուտքագրած ցանկացած բան՝ գրանցումներ, պատվերներ, հաղորդագրություններ, կարգավորումներ, և հետագայում ցույց տա դրանք կամ մեկ այլ անձի, ապա այո։ Զուտ տեղեկատվական կայքին առանց տվյալներ պահող ձևերի սովորաբար պետք չէ։