Ano ang Database? Gabay para sa mga Gumagawa ng App
Ang database ay nakaayos na imbakan ng impormasyon na sinusulatan at binabasa ng app: mga user, order, booking, at mensahe nito. Hindi tulad ng impormasyong nasa browser tab lang, nananatili ang datos sa database kahit i-refresh o i-restart ang app, at parehong mga tala ang nakikita ng lahat ng gumagamit ng app. Karamihan ng database ay nag-aayos ng datos sa mga table, halos kapareho ng mga sheet sa spreadsheet, pero may mahigpit na tuntunin na nagpapanatiling konsistent ng datos.
Bakit mahalaga ito kapag gumagawa ka gamit ang AI
Ang pinakakaraniwang nakakagulat sa mga gumagawa gamit ang AI ay ang app na mukhang tapos na pero nakakalimot ng lahat. Magdaragdag ka ng customer, ire-refresh ang page, at nawala na ito. Karaniwang ibig sabihin nito na sa memorya ng browser itinatago ng app ang datos, hindi sa database.
Nasa database din ang marami sa pinakamahahalagang desisyon mo, alam mo man o hindi:
- Ano ang itatala mo. Kapag hindi mo itinago ang status ng booking, hindi mo maipapakita kung alin ang kinansela.
- Paano nagkakaugnay ang mga bagay. Ang tanong kung puwedeng magkaroon ng maraming booking ang isang customer, o maraming serbisyo ang isang booking, ang humuhubog sa buong app.
- Sino ang puwedeng makakita ng ano. Karamihan ng pagkakamali sa privacy ay tungkol sa kung aling mga tala ang puwedeng basahin ng user.
Hindi mo kailangang ikaw mismo ang magdisenyo ng database. Pero ang pag-unawa sa mga pangunahing kaalaman ay nakakatulong para mailarawan nang malinaw ang datos mo at maagapan ang mga problema.
Isang halimbawa mula sa araw-araw
Isipin ang maayos na filing cabinet sa isang maliit na opisina.
Bawat drawer ay may iisang uri ng bagay: isang drawer para sa mga kliyente, isa para sa mga appointment, isa para sa mga invoice. Sa loob ng bawat drawer, sinusunod ng bawat folder ang iisang format, na may parehong fields na napunan. May sariling numero ng sanggunian ang bawat folder, at kapag pag-aari ng isang kliyente ang invoice, nakasulat sa folder ng invoice ang numero ng kliyenteng iyon sa halip na kopyahin ang buong file niya.
Iyan ang relational database. Ang mga drawer ay tables, ang mga folder ay rows, ang fields ay columns, ang mga numero ng sanggunian ay primary keys, at ang mga tala na tumuturo sa ibang folder ay foreign keys. Nagpapatupad din ng tuntunin ang mahusay na office manager, gaya ng walang appointment na walang petsa, at walang dalawang kliyenteng may parehong numero, tulad ng ginagawa ng database.
Halimbawang gawa: isang booking app para sa salon
Isipin na hiniling mo sa AI na gumawa ng booking site para sa isang hair salon. Makatuwirang database ang may apat na table.
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | Haircut | 45 | 40.00 |
| 2 | Colour | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | Lena Park | 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 |
Tingnan ang table na bookings. Hindi nito kinokopya ang pangalan at numero ng telepono ni Lena sa bawat booking; ang iniimbak nito ay customer_id = 101. Kapag pinalitan ni Lena ang numero ng telepono niya, nagbabago ito sa iisang lugar lang, at lahat ng booking ay magpapakita ng bago. Ito ang pangunahing ideya ng relational database: itago nang minsan lang ang bawat katotohanan, at mag-link dito.
Kaya ring sagutin ng parehong istruktura ang mga kapaki-pakinabang na tanong:
- "Anong oras ang bakante para kay Omar sa Biyernes?": tingnan ang mga booking ni Omar sa araw na iyon.
- "Magkano ang kinita ng mga colour appointment ngayong buwan?": pagsamahin ang bookings sa services at idagdag ang mga presyo.
- "Aling mga customer ang hindi nagpa-book sa nakalipas na 90 araw?": ihambing ang customers sa pinakabago nilang booking.
Mga paliwanag sa karaniwang termino
| Termino | Ibig sabihin |
|---|---|
| Table | Koleksyon ng iisang uri ng tala, gaya ng customers o bookings. |
| Row (record) | Isang item sa table: isang customer, isang booking. |
| Column (field) | Isang impormasyong mayroon ang bawat row, gaya ng email o presyo. |
| Primary key | Natatanging ID ng bawat row, kadalasang numero o random na string. |
| Foreign key | Column na tumuturo sa row sa ibang table, gaya ng customer_id sa bookings. |
| Schema | Kabuuang disenyo: aling mga table ang umiiral, ang kanilang column, at kung paano sila nagkakaugnay. |
| Query | Kahilingan para magbasa o magbago ng datos, gaya ng "lahat ng booking para bukas." |
| SQL | Structured Query Language, ang karaniwang wika sa pag-query ng relational na database. |
| Migration | Naka-save at paulit-ulit na pagbabago sa schema, gaya ng pagdaragdag ng column. |
| Index | Istrukturang panghanap na nagpapabilis ng paghahanap sa isang column, gaya ng index ng libro. |
| CRUD | Create, Read, Update, Delete: ang apat na pangunahing ginagawa ng app sa datos. |
| Backup | Kopya ng datos na maibabalik kung may magkamali. |
Mga uri ng database
| Uri | Paano nag-iimbak ng datos | Mga halimbawa | Mainam para sa |
|---|---|---|---|
| Relational (SQL) | Mga table na may nakapirming column at mga link sa isa't isa | Postgres, MySQL, SQLite | Karamihan ng business app: booking, tindahan, CRM, SaaS |
| Document (NoSQL) | Flexible na document na parang JSON | MongoDB, Firestore | Datos na malaki ang pagkakaiba ng hugis sa bawat tala |
| Key-value | Value na nakaimbak sa ilalim ng key | Redis | Caching, panandaliang datos gaya ng session |
Para sa halos lahat ng unang itinatayo ng founder o maliit na negosyo, ang relational na database ang ligtas na default.
Nasaan ang database sa loob ng app mo
Hindi direktang nakikipag-usap ang mga bisita sa database. Ang page sa browser nila (frontend) ay humihingi ng datos sa server mo (ang backend), kadalasan sa pamamagitan ng API. Tinitingnan ng server kung sino ang humihingi at kung may pahintulot siya, saka nagqu-query sa database at ibinabalik lang ang dapat makita ng taong iyon.
Mahalaga ang gitnang hakbang na iyon. Kung puwedeng mag-query ang browser nang direkta sa database na may buong access, sinumang magbukas ng developer tools ay mababasa ang lahat.
Mga karaniwang pagkakamali at maling akala
- Pagtatago ng datos sa browser lang. Ang browser storage (gaya ng localStorage) ay nasa iisang device at iisang browser. Ayos ito para sa naalalang filter, pero hindi para sa mga order.
- Paglalagay ng lahat sa iisang table. Ang iisang table na "bookings" na kinokopya ang pangalan, telepono at presyo ng serbisyo ng customer sa bawat row ay mabilis mawalan ng sync.
- Pag-iimbak ng password nang plain text. Dapat i-hash ang mga password, hindi itinatago nang nababasa. Tingnan ang ano ang authentication.
- Walang tuntunin sa datos. Kapag walang required na field at uniqueness rule, magkakaroon ka ng booking na walang petsa at dobleng customer.
- Nakakalimutan ang pagbura. Magpasya kung ang pagbura ng customer ay buburahin din ang mga booking niya, pananatilihin ang mga ito, o hahadlangan ang pagbura.
- Paggamit ng production data para mag-eksperimento. Subukan muna sa ligtas na lugar ang mga mapanganib na pagbabago, at magtabi ng backup.
- Pagturing sa spreadsheet bilang database habambuhay. Mahusay ang spreadsheet sa simula, pero nahihirapan ito sa maraming user na sabay-sabay at sa mga permission. Tingnan ang paano gawing app ang spreadsheet.
Ano ang hihingin sa AI builder mo
- "I-save ito sa database, hindi sa browser. Sabihin mo sa akin kung anong table ang gagawin mo."
- "Ipakita mo ang schema bilang simpleng table: bawat table, ang mga column nito, at kung paano sila nagkakaugnay."
- "Puwedeng magkaroon ng maraming booking ang isang customer; ang bawat booking ay may eksaktong isang serbisyo at isang staff member."
- "Gawing required at unique ang email para sa mga customer."
- "Pigilan ang dalawang booking para sa iisang staff member na magkapatong ang oras."
- "Ang naka-log in na may-ari lang ang puwedeng magbasa ng lahat ng booking; makikita lang ng customer ang sarili niyang booking. Ipatupad ito sa server."
- "Kapag binura ko ang isang serbisyo, huwag burahin ang mga nakaraang booking. Gawing inactive na lang ang serbisyo."
Mga database sa Mythex
Kapag kailangang mag-save ng datos ng app mo, nagdadagdag ang Mythex ng nakalaang Postgres database sa project. Puwede mo itong hilingin sa chat ("i-save ang mga sign-up sa waitlist sa database") o gamitin ang /database na command. Awtomatikong ipinapasa sa app mo ang mga detalye ng koneksyon, at ang agent ang gumagawa ng mga table. Natutulog ang database pagkatapos ng limang minutong walang gumagamit at gumigising sa susunod na request, at ang nagamit sa published na app ay sinisingil batay sa oras na gising ito, mula sa parehong credit balance ng pagbuo. Available ito sa Free at Pro. Sakop ng database docs ang mga detalye, at may mga panimulang punto na nakabatay sa datos sa mga app template.
Mga tanong
Ano ang database sa simpleng salita?
Ang database ay isang nakaayos na imbakan ng impormasyon na kayang sulatan at basahin ng app, gaya ng mga user, order o booking. Hindi tulad ng datos na nasa browser tab lang, nananatili ito kahit i-refresh ang page, i-restart ang server, o buksan ang app sa ibang device.
Database ba ang spreadsheet?
Kayang magtago ng spreadsheet ng parehong uri ng datos, pero hindi ito ginawa para sa app. Sinusunod ng totoong database ang mga tuntunin kung ano ang laman ng bawat column, maaasahang nag-uugnay ng mga table, nakakayanan ang maraming taong sabay-sabay na nagsusulat, at kinokontrol kung sino ang puwedeng magbasa ng ano.
Ano ang pagkakaiba ng SQL at NoSQL na database?
Ang SQL (relational) na database gaya ng Postgres at MySQL ay nag-iimbak ng datos sa mga table na may nakatakdang column at relasyon sa isa't isa. Ang NoSQL na database gaya ng MongoDB ay nag-iimbak ng mas flexible na document. Karamihan ng business app, gaya ng booking, CRM, o tindahan, ay bagay sa relational na modelo.
Kailangan ba ng app ko ng database?
Oo, kung kailangan nitong tandaan ang anumang ilalagay ng tao, gaya ng sign-up, order, mensahe, o settings, at ipakita ito sa ibang pagkakataon o sa ibang tao. Ang purong impormasyong website na walang form na nagsa-save ng datos ay kadalasang hindi nangangailangan nito.