Citat:
|
Originalno napisao ivanhoe
sta ima toliko lose u mesanju SQL-a i PHP-a ?
|
- ako SQL izmesas sa PHP kodom, pa naknadno dodje do neke izmene u strukturi ili nacinu obrade, moras da trazis po kodu gde si sve ubacivao upite na koji se te izmene odnose
- SQL cesto nije oneliner, a i ako jeste, obicno ima bar neki promenljivi deo, pa SQL upit u stvari sastavljas u letu, korsiteci PHP, sto je odmh i necitkije. To je bolje odvojiti u zasebnu funkciju, kojoj prosledjujes potrebne parametre, jer tako cinis kod citkijim. Inace sebi pravis veliku komplikaciju koja se nadovezuje na prethodni stav
- Murphy: ako u kodu upotrebis SQL upit na jednom mestu, sasvim je sigurno da ces ga upotrebiti na najmanje jos jednom
- Zlatno pravilo programiranja je pravilo uopstavanja problema. Ma koliko imao ociglednu situaciju koju treba da resis, sasvim je uputno gledati je sire i napraviti kod koji mozes da iskorsitis i u drugim situacijama. Za tvoj primer, recimo, sasvim je logicno napraviti mogucnost da parametrima odredis redosled slogova, broj slogova koji se izvlace iz tabele pa cak i filter jer to ne moze da ti ne zatreba.
Mislim da je ova tema pokrenuta sa stavom da nije pitanje treba li koristiti neki wrapper, nego sta i kako koristiti. Ne valja se vracati unazad, na nacin programiranja od pre procedura i objekata.
Tvoj primer je u neku ruku neobican, jer jedan problem resavas objektnim pristupom, koji je i nastao iz potrebe da se kod pise modularno, uopsteno i da bude upotrebljiv u raznim situacijama a sa druge strane sve te principe potires mesanjem SQL-a direktno u celu pricu.
Naravno, i sam kazes da ovo radi kada su u pitanju jednostavni poslovi, a siguran sam da svako od nas ne preza da ovako napise neki privremeni skript, jer je brze i ociglednije, ali, ako pises kod koji treba da bude u upotrebi dugo vremena, treba da ga odrzavas (ili jos gore, da ga odrzava neko drugi), mesanje SQL-a u PHP je medvedja usluga.