Paano Magdagdag ng Database sa App Mo (Nang Hindi Nawawala ang Data Mo Sa Huli)

Para magdagdag ng database sa app mo, pumili ng managed relational database (Postgres ang karaniwang default), itago ang connection string nito sa server-side secret, gumawa ng isang table para sa bawat uri ng bagay na iniimbak ng app mo, at ipagawa sa backend mo, hindi sa browser, ang pagbasa at pagsulat dito. Kung gumagamit ka ng AI app builder, kadalasan ay sapat nang sabihin ang "i-save ito sa database" at ang agent na ang gagawa ng tables at code; ang trabaho mo ay ilarawan nang malinaw ang data at tiyaking talagang nase-save ito.

Sakop ng guide na ito kung kailan mo kailangan ng database, ang mga pangunahing opsyon, kung paano ilalarawan ang data mo, at ang mga pagkakamaling nagdudulot ng nawawala o nalalantad na data.

Kailan kailangan ng app mo ng database

Kailangan ng database kapag kailangang may maalala ang app mo pagkatapos isara ang page, o magbahagi ng data sa mga tao. Mga karaniwang senyales:

• May ipinapasa ang mga bisita: form, sign-up, booking, o order
• May sariling naka-save na content ang mga user na may account
• Kailangang makita o i-edit ng admin ang ginawa ng iba
• Gusto mo ng report o bilang sa paglipas ng panahon

Hindi mo kailangan ng isa para sa static site na pareho ang nakikita ng lahat, gaya ng portfolio o simpleng landing page. Kung hindi ka sigurado kung ano talaga ang database, basahin muna ang ano ang database.

Mga opsyon mo

Para sa karamihan ng maliit at katamtamang web app, tamang default ang relational database tulad ng Postgres. Magaling ito sa relasyon (may maraming order ang isang customer), pinapanatiling consistent ang data, at nagbibigay-daan na sagutin ang mga tanong sa hinaharap gamit ang SQL. Tingnan ang ano ang Postgres para sa paliwanag na madaling maintindihan.

Ilarawan ang data mo bago mag-build

Ang pinakamakabuluhang magagawa mo ay isulat ang mga bagay na iniimbak ng app mo at kung paano sila nagkakaugnay. Hindi mo kailangan ng database jargon. Para sa booking app:

• Customers: pangalan, email, telepono
• Services: pangalan, tagal, presyo
• Bookings: aling customer, aling service, oras ng simula, status (pending, confirmed, cancelled)

Tatlong table na iyan. Ang "aling customer" at "aling service" ay nagiging mga link (foreign keys) sa pagitan nila. Mas mahalagang tama ito nang maaga kaysa anumang pagpili ng teknolohiya, dahil mas mahirap baguhin ang hugis ng data na may totoong rows na kaysa baguhin ang layout ng page.

Mga gabay na dapat tandaan:

• Isang table para sa bawat uri ng bagay. Huwag ilagay ang mga order sa text column ng customer.
• Bigyan ng ID at created-at time ang bawat row. Kakailanganin mo ang pareho sa hinaharap.
• Gumamit ng tamang uri. Petsa bilang petsa, pera bilang buong sentimo o decimal type, hindi bilang text.
• Markahan ang required na field bilang required. Hayaang tanggihan ng database ang maling data, hindi lang ng form.

Mga halimbawang prompt

Simulan sa isang feature sa isang pagkakataon sa halip na ibagsak ang buong schema:

Magdagdag ng database sa app na ito. Gumawa ng bookings table na may pangalan ng customer, email, service, oras ng simula at status (pending, confirmed, cancelled; default na pending). I-save sa table ang mga isinumiteng booking mula sa form, magpakita ng success message, at magdagdag ng admin page na naglilista ng bookings, pinakabago muna.

Pagkatapos, palawakin:

Magdagdag ng services table (pangalan, tagal sa minuto, presyo sa sentimo). Palitan ang free-text na service field sa bookings ng link sa services, at i-migrate ang mga umiiral na booking nang hindi binubura ang mga ito.

At higpitan:

Siguraduhing nangyayari sa server ang lahat ng pagbasa at pagsulat sa database. Hindi dapat matanggap ng browser ang connection string ng database. I-validate ang email at oras ng simula sa server bago mag-insert.

Hakbang-hakbang

1. Ilista ang data mo gaya ng nasa itaas: mga bagay, field, at mga link sa pagitan nila.
2. Gawin ang database. Sa AI builder, humingi nito sa chat. Sa ibang lugar, gumawa ng managed Postgres instance at kopyahin ang connection string nito.
3. Itago ang connection string bilang secret (environment variable sa server), hindi sa code. Tingnan ang environment variables at secrets.
4. Gawin ang mga table. Gumamit ng migrations, mga versioned na script na nagbabago ng schema, para maulit at mabaligtad ang mga pagbabago.
5. Buuin ang server routes na gumagawa, bumabasa, nag-a-update at nagbubura ng mga row (CRUD). Tumatawag sa mga route na ito ang browser; hindi ito direktang nakikipag-usap sa database.
6. Ikabit ang UI sa mga route na iyon: mga form na nagse-save, listahang nagla-load, at empty state kapag wala pang laman.
7. Subukan ang persistence. Mag-submit ng isang bagay, i-reload ang page, buksan sa ibang browser. Kung wala roon ang data, hindi ito na-save sa database.
8. Suriin ang access. Mag-log in bilang pangalawang user at tiyaking hindi mo makikita o mae-edit ang data ng unang user.
9. I-publish, saka subukan ulit sa live URL, dahil maaaring iba ang connection ng published app sa preview mo.

Mga karaniwang pagkakamali

• Pag-save sa browser at pag-akalang naka-save na ito. Mukhang gumagana ang localStorage hanggang may magbukas ng app sa ibang device. Laging subukan sa pangalawang browser.
• Paglalagay ng connection string sa frontend code. Mababasa ng sinuman ang frontend code. Sa kanila na ang buong database mo.
• Walang access check. Ang "ipakita ang mga order ko" ay dapat mag-filter ayon sa naka-login na user sa server, hindi sa UI. Ito ang pinakakaraniwang security hole sa mga app na AI ang gumawa; sakop ito ng aming security checklist.
• Mapanirang pagbabago sa schema. Ang paghiling na "palitan ang pangalan ng table" o "baguhin ang istruktura" ay maaaring mag-drop at mag-recreate nito. Kapag may totoong data na, sabihing "i-migrate ang umiiral na mga row, huwag magbura ng kahit ano".
• Pag-store ng file sa database. Dapat nasa file storage ang mga larawan at PDF, na may URL o key lang nila sa table. Tingnan ang paano magdagdag ng file uploads.
• Walang backup. Alamin kung paano nagba-backup ang platform mo ng data at kung paano ito ibabalik bago ka pa magkaroon ng customer.

Checklist

• May sariling table ang bawat uri ng bagay, na may ID at created-at time
• Ipinapatupad ng database ang required na field at mga uri
• Nasa server-side secrets lang ang connection string
• Dumadaan sa server routes ang lahat ng pagbasa at pagsulat
• Makakabasa at makakabago lang ng sarili nilang row ang bawat user
• Nananatili ang data pagkatapos ng reload at lumalabas sa ibang browser
• Gumagamit ng migrations ang mga pagbabago sa schema at pinapanatili ang umiiral na row
• Alam mo kung paano gumagana ang backup at restore
• Nasubukan na ang live app pagkatapos i-publish

Pagdaragdag ng database sa Mythex

Sa Mythex, puwedeng magkaroon ang bawat project ng sarili nitong dedicated Postgres database, sa Free at Pro. Kadalasan ay hindi mo kailangang mag-click ng hiwalay na "attach" button: humingi sa chat ("mag-save ng waitlist emails sa database") o i-type ang /database, at ii-inject ang connection details sa workspace at sa published app mo. Ipinapakita ng project settings kung aktibo ang database.

Nagso-sleep ang database pagkatapos ng 5 minutong walang aktibidad at gumigising sa susunod na request. Sinisingil ang published usage batay sa oras na aktuwal itong gising, mula sa parehong credit balance na ginagamit mo sa pag-build. Kung nagdagdag ka ng database pagkatapos mong mag-publish, i-publish ulit para makuha ng live app ang pagbabago.

Tingnan ang Database at ang recipe na Build a CRUD app sa docs. Para sa login side ng per-user data, basahin ang paano magdagdag ng login sa app mo.

Mga tanong