trebuie să includă toate câmpurile
Cine a spus asta?
da chiar și în ordinea corectă.
Cine a spus asta?
Există o funcție pentru Actualizare.
E nouăzeci.
Nu are sens să păcăliți întreaga clasă doar pentru a putea adăuga date la actualizare din matrice. Ați legat-o cu mâna și cu piciorul.
D pentru că lucrați numai la cheia primară - nu? Și pe un compozit deja în orice fel.
U actualizați numai cu valori. Și dacă funcția ar trebui utilizată în cerere? Cum ar fi ACUM (), INET_ATON ()?
Din moment ce nu puteți introduce decât proastă lista. Și în viață această interogare are o sintaxă mult mai bogată
despre R în general tăcut. Acolo aveți iad, gunoi și deșeuri.
Și acest lucru, în ciuda faptului că trebuie să învățați să adăugați câteva tipuri de date nestandardizate.
- Iată întregul CRUD în 5 rânduri
Mulțumesc! Chiar nu știam despre această formă de INSERT:
INSERTAȚI ÎN tabelul SET `sum` = '123';
Deci, scrieți că nu are nici un sens să vă opriți pentru întreaga clasă. Dar, la urma urmei, funcția mea de actualizare sau de adăugare ar trebui să adauge date în baza de date. Datele introduse în formular (de exemplu, în panoul de administrare). Aceste date sunt transmise funcției ca matrice. O matrice este un set de nume pentru toate câmpurile, un set de valori de intrare în aceste câmpuri, un set de date despre câmpurile care sunt necesare, care nu sunt prezente și așa mai departe. Ie funcția nu ar trebui să formeze doar o interogare SQL din aceste date, ci trebuie să verifice corectitudinea datelor introduse, să verifice dacă sunt introduse toate datele solicitate. Și returnați rezultatul: fie un cod de operare de succes, fie un cod de eroare cu câmpuri goale sau completate incorect, astfel încât mesajele corespunzătoare să fie afișate în vizualizare. Este un astfel de funcționar nevrednic să scrie o clasă separată și o funcție separată, care va fi apoi moștenită? Ie Voi lua această funcție universală pregătită, care poate schimba sau adăuga date în orice tabel și le poate redefini pentru nevoi specifice sau nu va suprascrie deloc. Nu este un CRUD (în acest caz vorbeam doar despre Actualizare sau Creare). Sau în esență nu înțeleg ceva?
După ce credeți, puneți-vă o întrebare. Care este de 100 de ori mai important decât suferința cu INSERT. Așa că scrieți că "nu scriu variabile direct în interogare fără preprocesare". Și unde ți-ai făcut tratamentul pentru a avea vreun sens? Ce protejează de ceva? Că este drept, la urma urmei?
FanatPHP. Încerc doar să răspund este util. și nu știu cum puteți răspunde la astfel de întrebări în acest fel. De asemenea, adesea văd că oamenii fac multe greșeli pur și simplu pentru că nu știu că acest lucru sau faptul că - există.
Se va familiariza cu pdo, migrația, veți vedea, va veni la schemă. Și multe lucruri vor cădea în loc.
Descrieți totul într-un post care este puțin probabil să reușească. O abatere de la sql pur este un început bun, în opinia mea.
Și cu atât mai mult, să fie atașat la un anumit sub-este inutil. Este mai bine, în opinia mea, să înțelegeți că procesul este, în general, rahat (creați propria clasă de acces la "obiectele" din baza de date.
Eck korezhit :) Greu să-i recunosc greșit? În primul paragraf, am avut dreptate, iar în al patrulea rând, se pare că sunt din nou "doar într-un singur" drept :) În plus, niciodată nu v-ați dat seama că tipul scrie doar acel strat. Adică, greșești în toate privințele. Ei bine, și că totul a intrat în vigoare: dacă nu răspundeți la întrebare - nu răspundeți.
Articole similare
Trimiteți-le prietenilor: