Ինչպես ավելացնել տվյալների բազա ձեր հավելվածին (առանց տվյալները հետո կորցնելու)

Հավելվածին տվյալների բազա ավելացնելու համար ընտրեք կառավարվող հարաբերական տվյալների բազա (սովորաբար՝ Postgres), միացման տողը պահեք սերվերային գաղտնիքում, ստեղծեք մեկ աղյուսակ յուրաքանչյուր տեսակի համար, որ ձեր հավելվածը պահում է, և թույլ տվեք, որ ձեր backend-ը՝ ոչ բրաուզերը, կարդա և գրի այդ բազայում։ Եթե կառուցում եք AI հավելվածի կառուցիչով, սովորաբար բավական է ասել «պահիր սա տվյալների բազայում», և գործակալը ստեղծում է աղյուսակները և կոդը։ Ձեր գործն է տվյալները հստակ նկարագրել և ստուգել, որ դրանք իրոք պահպանվում են։

Այս ուղեցույցը ներկայացնում է, թե երբ է տվյալների բազան անհրաժեշտ, հիմնական տարբերակները, ինչպես նկարագրել ձեր տվյալները և այն սխալները, որոնք հանգեցնում են տվյալների կորստի կամ արտահոսքի։

Ե՞րբ է հավելվածին տվյալների բազա պետք

Տվյալների բազա է պետք, երբ ձեր հավելվածը պետք է հիշի ինչ-որ բան էջը փակելուց հետո, կամ կիսի տվյալները մարդկանց միջև։ Տիպիկ նշանները.

• Այցելուները ինչ-որ բան են ուղարկում՝ ձև, գրանցում, ամրագրում, պատվեր
• Օգտատերերն ունեն հաշիվներ՝ իրենց պահած բովանդակությամբ
• Ադմինը պետք է տեսնի կամ խմբագրի ուրիշների ստեղծածը
• Ձեզ պետք են հաշվետվություններ կամ հաշվարկներ ժամանակի ընթացքում

Ստատիկ կայքի համար, որտեղ բոլորը տեսնում են նույն բովանդակությունը, օրինակ՝ portfolio կամ պարզ landing էջ, տվյալների բազա պետք չէ։ Եթե տվյալների բազան ինչ լինելը պարզ չէ, նախ կարդացեք տվյալների բազան ինչ է։

Ձեր տարբերակները

Այս փոքր և միջին վեբ հավելվածների մեծ մասի համար հարաբերական տվյալների բազան, ինչպիսին է Postgres-ը, ճիշտ լռելյայն ընտրությունն է։ Այն լավ է կապերի հետ (մի հաճախորդ ունի շատ պատվերներ), պահում է տվյալների հետևողականությունը և թույլ է տալիս հետագայում հարցումներ անել SQL-ով։ Postgres-ի պարզ նկարագրության համար տես Postgres-ը ինչ է։

Նկարագրեք ձեր տվյալները նախքան կառուցելը

Ամենաօգտակար բանը, որ կարող եք անել, գրի առնել այն բաները, որ ձեր հավելվածը պահում է, և ինչպես են դրանք կապված։ Տվյալների բազայի տերմինաբանություն պետք չէ։ Ամրագրման հավելվածի համար.

• Հաճախորդներ. անուն, էլ․ փոստ, հեռախոս
• Ծառայություններ. անուն, տևողություն, գին
• Ամրագրումներ. որ հաճախորդը, որ ծառայությունը, սկզբի ժամանակը, կարգավիճակը (սպասվող, հաստատված, չեղարկված)

Սա երեք աղյուսակ է։ «Որ հաճախորդը» և «որ ծառայությունը» դառնում են կապեր (foreign key) աղյուսակների միջև։ Սա ճիշտ ստանալը վաղ փուլում շատ ավելի կարևոր է, քան ցանկացած տեխնոլոգիական ընտրություն, քանի որ արդեն իրական տողեր ունեցող տվյալների կառուցվածքը փոխելը ավելի դժվար է, քան էջի դասավորությունը։

Մի քանի գործնական կանոններ.

• Մեկ աղյուսակ յուրաքանչյուր տեսակի համար։ Պատվերները մի տեքստային սյունակում հաճախորդի մեջ մի խցկեք։
• Յուրաքանչյուր տողին տվեք ID և ստեղծման ժամանակ։ Երկուսն էլ ձեզ հետագայում հարկավոր կլինեն։
• Օգտագործեք ճիշտ տիպեր։ Ամսաթվերը՝ որպես ամսաթվեր, գումարը՝ որպես ամբողջ սենթեր կամ տասնորդական տիպ, ոչ թե տեքստ։
• Նշեք պարտադիր դաշտերը որպես պարտադիր։ Թող տվյալների բազան մերժի սխալ տվյալները, ոչ միայն ձևը։

Հուշումների օրինակներ

Սկսեք մեկ գործառույթից, ոչ թե ամբողջ սխեման մեկ անգամ տվեք.

Ավելացրու տվյալների բազա այս հավելվածին։ Ստեղծիր bookings աղյուսակ՝ հաճախորդի անունով, էլ․ փոստով, ծառայությամբ, սկզբի ժամանակով և կարգավիճակով (pending, confirmed, cancelled; լռելյայն՝ pending)։ Պահիր ամրագրման ձևից եկած գրանցումները, ցույց տուր հաջողության հաղորդագրություն և ավելացրու ադմինի էջ, որտեղ ամրագրումները ցուցադրվում են նորից հին՝ վերևում։

Հետո ընդլայնիր այն.

Ավելացրու services աղյուսակ (անուն, տևողություն րոպեներով, գին սենթերով)։ Bookings-ի ազատ տեքստով ծառայության դաշտը փոխարինիր կապով դեպի services, և գոյություն ունեցող ամրագրումները տեղափոխիր՝ առանց ջնջելու։

Եվ խստացրու այն.

Համոզվիր, որ տվյալների բազայի բոլոր կարդալն ու գրելը տեղի է ունենում սերվերի վրա։ Բրաուզերը երբեք չպետք է ստանա տվյալների բազայի միացման տողը։ Ներդնելուց առաջ սերվերի վրա ստուգիր էլ․ փոստը և սկզբի ժամանակը։

Քայլ առ քայլ

1. Ցուցակագրեք ձեր տվյալները վերևի պես՝ բաներ, դաշտեր, կապեր դրանց միջև։
2. Ստեղծեք տվյալների բազան։ AI կառուցիչում խնդրեք չաթում։ Այլուր ստեղծեք Postgres-ի կառավարվող օրինակ և պատճենեք դրա միացման տողը։
3. Պահեք միացման տողը որպես գաղտնիք (սերվերի միջավարձական փոփոխական), երբեք կոդում։ Տես միջավայրի փոփոխականներ և գաղտնիքներ։
4. Ստեղծեք աղյուսակները։ Օգտագործեք migrations՝ տարբերակված սկրիպտներ, որոնք փոխում են սխեման, որպեսզի փոփոխությունները կրկնվող և հետադարձելի լինեն։
5. Կառուցեք սերվերային երթուղիները, որոնք ստեղծում, կարդում, թարմացնում և ջնջում են տողեր (CRUD)։ Բրաուզերը այս երթուղիները կանչում է, այն երբեք անմիջապես չի խոսում տվյալների բազայի հետ։
6. Միացրեք UI-ը այդ երթուղիներին՝ պահող ձևեր, բեռնվող ցուցակներ, դատարկ վիճակի ցուցադրում, երբ դեռ ոչինչ չկա։
7. Ստուգեք պահպանումը։ Ուղարկեք ինչ-որ բան, վերբեռնեք էջը, բացեք այն մեկ այլ բրաուզերում։ Եթե տվյալները չկան, դրանք տվյալների բազայում չեն պահպանվել։
8. Ստուգեք մուտքը։ Մտեք որպես երկրորդ օգտատեր և համոզվեք, որ չեք կարող տեսնել կամ խմբագրել առաջին օգտատիրոջ տվյալները։
9. Հրապարակեք, ապա նորից փորձարկեք կենդանի URL-ի վրա, քանի որ հրապարակված հավելվածը կարող է օգտագործել այլ միացում, քան ձեր նախադիտումը։

Սովորական սխալներ

• Պահել բրաուզերում և կարծել, թե պահված է։ localStorage-ը աշխատում է թվացյալ, մինչև ինչ-որ մեկը բացի հավելվածը մեկ այլ սարքում։ Միշտ փորձարկեք երկրորդ բրաուզերում։
• Միացման տողը frontend կոդում։ Ցանկացած ոք կարող է կարդալ frontend կոդը։ Դա նրանց տալիս է ձեր ամբողջ տվյալների բազան։
• Մուտքի ստուգումների բացակայություն։ «Ցույց տուր իմ պատվերները» պետք է ֆիլտրվի մուտք գործած օգտատիրոջ կողմից սերվերի վրա, ոչ թե UI-ում։ Սա AI-ով կառուցված հավելվածների ամենատարածված անվտանգության խոցն է․ մեր անվտանգության ստուգաթերթը այն լուսաբանում է։
• Կործանարար սխեմայի փոփոխություններ։ «Վերանվանիր աղյուսակը» կամ «փոխիր կառուցվածքը» կարող է աղյուսակը ջնջել և նորից ստեղծել։ Երբ իրական տվյալներ կան, ասեք՝ «տեղափոխիր գոյություն ունեցող տողերը, ոչինչ մի ջնջիր»։
• Ֆայլերը տվյալների բազայում պահելը։ Նկարները և PDF-երը պատկանում են ֆայլերի պահոցին, իսկ աղյուսակում պետք է լինի միայն դրանց URL-ը կամ բանալին։ Տես ինչպես ավելացնել ֆայլերի վերբեռնում։
• Առանց պահուստների։ Իմացեք, թե ձեր պլատֆորմը ինչպես է կրկնօրինակում տվյալները և ինչպես կարող եք վերականգնել դրանք, մինչև ունենաք հաճախորդներ։

Ստուգաթերթ

• Յուրաքանչյուր տեսակի բան ունի իր աղյուսակը՝ ID-ով և ստեղծման ժամանակով
• Պարտադիր դաշտերն ու տիպերը պարտադրվում են տվյալների բազայի կողմից
• Միացման տողը գտնվում է միայն սերվերային գաղտնիքներում
• Բոլոր կարդալն ու գրելը անցնում է սերվերային երթուղիներով
• Յուրաքանչյուր օգտատեր կարող է կարդալ և փոխել միայն իր տողերը
• Տվյալները պահպանվում են վերբեռնումից հետո և երևում են այլ բրաուզերում
• Սխեմայի փոփոխությունները օգտագործում են migrations և պահում են գոյություն ունեցող տողերը
• Գիտեք, թե ինչպես են աշխատում կրկնօրինակումները և վերականգնումը
• Կենդանի հավելվածը փորձարկվել է հրապարակումից հետո

Տվյալների բազայի ավելացումը Mythex-ում

Mythex-ում յուրաքանչյուր նախագիծ կարող է ունենալ իր առանձին Postgres տվյալների բազան և՛ Free, և՛ Pro պլաններում։ Սովորաբար առանձին «միացնել» կոճակ պետք չէ․ խնդրեք չաթում («պահիր էլ․ փոստերը ցուցակի համար տվյալների բազայում») կամ գրեք /database, և միացման տվյալները ներդրվում են աշխատանքային տարածք և ձեր հրապարակված հավելված։ Նախագծի կարգավորումները ցույց են տալիս, թե տվյալների բազան ակտիվ է արդյոք։

Տվյալների բազան քնում է 5 րոպե անգործության հետո և արթնանում հաջորդ հարցման ժամանակ։ Հրապարակված օգտագործումը վճարվում է այն ժամանակի համար, երբ այն իրականում արթուն է եղել, նույն կրեդիտների հաշվեկշռից, որ օգտագործում եք կառուցման համար։ Եթե տվյալների բազան ավելացնում եք արդեն հրապարակելուց հետո, նորից հրապարակեք, որպեսզի կենդանի հավելվածը այն ընդունի։

Տես Տվյալների բազա և CRUD հավելված կառուցել բաժինը փաստաթղթերում։ Օգտատերերի տվյալների մուտքի մասի համար կարդացեք ինչպես ավելացնել մուտք ձեր հավելվածին։

Հարցեր