Ano ang CRUD? Create, Read, Update, Delete, Ipinaliwanag

Ang CRUD ay nangangahulugang create, read, update at delete, ang apat na pangunahing bagay na ginagawa ng app sa naka-store na data. Ang pagdagdag ng bagong customer ay create, ang pagtingin sa listahan ng customers ay read, ang pagpalit ng phone number niya ay update, at ang pagtanggal sa kanya ay delete. Karamihan ng business apps, gaya ng CRM, booking systems, inventory trackers at admin panels, ay pangunahing CRUD na may mga patakaran at magandang layout sa ibabaw.

Bakit ito mahalaga kapag gumagawa ka gamit ang AI

Ang CRUD ang bokabularyong nagpapalit ng malabong ideya ng app sa tumpak na hiling. Ang “app para sa pamamahala ng mga supplier namin” ay nag-iiwan sa AI na manghula. Ang “i-create, ilista, i-edit at burahin ang mga supplier, na may mga field na ito” ay nagsasabi nang eksakto kung anong mga screen, database operation at server routes ang bubuuin.

Nagbibigay din ito ng checklist para sa pagsubok. Para sa bawat uri ng record sa app mo, may apat kang tanong: kaya ko bang magdagdag, makita, baguhin at alisin ito, at ang mga tamang tao lang ba ang makakagawa ng bawat isa? Nakakagulat na dami ng app na gawa ng AI ang nakakapag-create pero hindi nakakapag-edit, o nagpapahintulot sa sinuman na magbura ng kahit ano.

Isang halimbawang pang-araw-araw: kahon ng recipe cards

Isipin ang kahon ng recipe cards sa istante ng kusina.

• Create: magsulat ng bagong card at ilagay ito sa kahon.
• Read: lakarin ang mga card, o hanapin ang isa para sa lasagna.
• Update: ekisan ang “200g keso” at isulat ang “250g.”
• Delete: kunin ang isang card at itapon.

Ngayon, idagdag ang mga patakaran: ang punong kusinero lang ang puwedeng magtapon ng card, bawat card ay dapat may pamagat, at walang puwedeng maglagay ng dalawang card na may parehong pangalan. Iyon ay CRUD app na may validation at permissions, at ganoon ang karamihan ng totoong app.

Paano lumalabas ang CRUD sa bawat layer

Lumilitaw ang bawat operasyon sa screen, sa server at sa database. Ang pagkikita nilang magkatabi ay nagpapaliwanag ng marami tungkol sa paggawa ng app.

Ang screen ang frontend, ang API request ang paraan ng pakikipag-usap ng frontend sa backend, at ang SQL ang paraan ng pakikipag-usap ng backend sa database. Kung bago sa iyo ang mga salitang iyon, tingnan ang ano ang API at ano ang database.

Isang halimbawang gawa: tracker ng hiniram na kagamitan

May media department ng isang paaralan na nagpapautang ng mga camera at mikropono sa mga estudyante, at madalas nilang nawawala ang bakas ng mga ito. Gusto nila ng simpleng app.

Ang mga record. Dalawang uri ng bagay: kagamitan (pangalan, uri, serial number, kondisyon) at pautang (aling kagamitan, aling estudyante, petsa ng paglabas, petsa ng dapat ibalik, petsa ng pagbalik).

CRUD para sa kagamitan:

• Create: idinadagdag ng staff ang bagong camera kasama ang serial number nito. Patakaran: dapat natatangi ang serial numbers.
• Read: listahan ng lahat ng kagamitan, na maaaring i-filter ayon sa uri at sa “available ngayon”; detail page na nagpapakita ng kasaysayan ng pautang ng isang item.
• Update: baguhin ang kondisyon sa “kailangang ayusin.”
• Delete: hindi ito tunay na delete. Kapag nabura ang camera na may 30 nakaraang pautang, mawawalan ng link ang mga record ng pautang. Sa halip, markahan itong “retired” para mawala sa listahan ng available pero manatili ang kasaysayan nito. Tinatawag itong soft delete.

CRUD para sa pautang:

• Create: ilabas ang item sa estudyante. Patakaran: hindi puwedeng ilabas ang item na nasa pautang na.
• Read: listahan ng “overdue” na pautang, kung saan lumipas na ang petsa ng dapat ibalik at walang petsa ng pagbalik.
• Update: itala ang petsa ng pagbalik kapag bumalik ang item.
• Delete: staff lang, para sa mga pautang na naipasok nang mali.

Permissions. Puwedeng basahin ng mga estudyante kung ano ang available; staff lang ang puwedeng mag-create, mag-update o mag-delete. Tumatakbo ang mga tseke na ito sa server, hindi lang sa pagtatago ng mga button.

Iyon ang buong app. Ang mga kawili-wiling bahagi, gaya ng walang doble-pautang, listahan ng overdue, at kasaysayan bawat item, ay mga patakaran at query sa ibabaw ng simpleng CRUD.

Mahahalagang termino

• Record (row): isang item, gaya ng isang supplier o isang pautang.
• Entity / resource: uri ng record, gaya ng “suppliers.” Kadalasan, may sariling table at sariling hanay ng CRUD screens ang bawat isa.
• Validation: tseke sa input, gaya ng kinakailangang fields, wastong email, positibong dami. Gawin ito sa form para sa kaginhawahan at sa server para sa kaligtasan.
• Soft delete: pagmamarka ng record bilang nabura o naka-archive sa halip na tanggalin ito, para mapanatili ang kasaysayan at mga link.
• Pagination: pagpapakita ng mahabang listahan nang isang pahina sa isang pagkakataon, para bumilis ang app.
• Audit log: talaan kung sino ang gumawa, nagbago o nagbura ng ano, at kailan.
• Admin panel: hanay ng CRUD screens para sa staff na mamahala ng data ng app.

Mga karaniwang pagkakamali at maling akala

• Pagkalimot sa isa sa apat. Madalas na may create at read lang ang app pero walang edit, kaya kailangang burahin at i-type muli ang bawat typo. Tingnan ang apat para sa bawat entity.
• Mga delete na nakakasira ng bagay. Ang pagbura ng customer na may invoice ay puwedeng mag-iwan ng ulilang invoice o magbura ng kasaysayan. Magpasya kada entity: harangin ang delete, soft delete, o burahin din ang mga kaugnay na record.
• Permissions sa interface lang. Hindi napipigilan ng pagtatago ng Delete button ang sinumang magpadala ng DELETE request. Dapat suriin ng server kung sino ang humihiling.
• Pag-update gamit ang ID nang hindi tinitingnan ang may-ari. Kung puwedeng i-edit ng user A ang /api/notes/42 sa pagpalit ng numero sa URL, puwede niyang i-edit ang note ng user B. Dapat kumpirmahin ng bawat update at delete na pag-aari ng humihiling ang record.
• Walang kumpirmasyon sa delete. Hindi dapat makasira ng data ang isang maling pindot. Maglagay ng hakbang ng kumpirmasyon, o undo.
• “Basic ang CRUD kaya hindi sulit gawin.” Maraming mahalagang produkto ang CRUD apps na mas angkop sa workflow kaysa sa generic na tool.

Ano ang hihilingin sa AI builder mo

Gamitin ang pattern na ito para sa bawat entity, isa-isa:

Gumawa ng suppliers feature na may list, create, edit at delete. Mga field: name (kinakailangan), contact email (wastong email), phone, category (isa sa: food, packaging, cleaning), notes. List view na may search ayon sa pangalan at filter ayon sa category, 20 bawat pahina. Kumpirmahin bago magbura; kung may orders ang supplier, i-archive sa halip na burahin. Tanging naka-log in na staff lang ang puwedeng gumawa, mag-edit o mag-archive, at ipatupad ito sa server.

Pagkatapos, subukan ang lahat ng apat na operasyon, bilang user na may pahintulot at bilang taong hindi dapat magkaroon ng access. Kapag gumana na ang isang entity, idagdag ang susunod. Ipinapakita ng paano gumawa ng internal tool kung paano nagiging kumpletong admin app ang mga CRUD screen, at ipinapaliwanag ng ano ang Postgres ang database na kadalasang kinalalagyan ng mga app na ito.

CRUD apps sa Mythex

Isa ang CRUD apps sa mga bagay na pinakamahusay gawin ng AI app builders, at hindi naiiba ang Mythex. Hilingin sa chat ang entity at mga field nito, at ikakabit ng Mythex ang Postgres database sa project, gagawin ang table, at bubuuin ang listahan, form at detail screens sa live preview; maaari mo nang patakbuhin ang /test para suriin ang daloy. May CRUD app recipe ang docs na may starter prompt, at magagandang panimula ang internal tool builder at dashboard templates.

Mga tanong