[ sandib @ 12.10.2016. 11:27 ] @
Code:
imam gomilu polja gde se unose samo brojvi pocevsi sa maticnim brojem i pibom plus neke ogromne tabele gde su unose samo projevi.
da li mogu da definisem sve inpute sa id="unos_brojeva" sto bi izgledalo npr ovako...

input forma:
Code:

<tr>
    <td>Matični broj:</td>
    <td><input type="text" name="maticni_broj" id="unos_bojeva"/></td>
</tr>


php

Code:

<?php

if (isset($_POST["submit"])) {
$value2 = $_POST["unos_brojeva"];
if(empty($value2)) {
    $msg = '<span class="error"> Please enter a value</span>';
} else if(!is_numeric($value2)) {
    $msg = '<span class="error"> Data entered was not numeric</span>';
} else {
    /* Success */
}
}

?>


probao sam gomilu nekih kombinacija i nista se ne desava.. samo punim bazu..

probao sam $value2 da bude $number onda da "unos_brojeva" bude i "maticni_broj" itd...
[ plus_minus @ 12.10.2016. 13:24 ] @
Za početak ..

Code (html):


<input type="number" min="0" max="999999" step="1">

 


min, max ... step, to je sve proizvoljno..

staviš i value="61019650025" ... proizvoljno..

A posle u php odradiš type_cast u int

Code (php):


$input_type_number_id = ((int) $input_type_number_id);

 


.. npr.

Ili jednostavno spakuješ unos kao string.. baš kao što proveravaš.

možda je bolje da sa ctype_digit umesto is_numeric odradiš proveru, pre nego što uneseš u bazu.

Code (php):


if (!ctype_digit($var_name)) echo 'error';
else { /* ... process further ... */ }

 


Sve u svemu, šta te još zeza (šta sve još može da te zeza..) prilikom unosa u bazu, za to je potrebno možda još informacija, možda još source code primera/detalja ..

Elem, ne zaboravi da ne možeš da imaš više id atributa sa istim nazivom - po stranici.
Bez obzira jel' taj id u sklopu forme ili ne. id naziv MORA da bude unikatan.

Dakle, ne može svaki input type="number" (ili text) da ima id="unos_brojeva" ..
mora da bude id="unos_brojeva_1", id="unos_brojeva_2", id="unos_brojeva_3" ... itd.

[Ovu poruku je menjao plus_minus dana 12.10.2016. u 14:41 GMT+1]
[ sandib @ 12.10.2016. 13:37 ] @
sad cu da probam.. hvala puno :)
[ sandib @ 12.10.2016. 13:49 ] @
ovo je samo isecak neki od formi

Code:
<form action="number_validation.php" action="connect.php" method="post"/>
<table width="521" border="0" align="center">
  <tbody>
        <tr>
          <td width="257">Naziv objekta:</td>
          <td width="254"> <input type="text" name="naziv_objekta" /></td>
        </tr>
        <tr>
          <td>Matični broj:</td>
          <td><input type="text" name="maticni_broj" id="unos_bojeva"/></td>
        </tr>
        <tr>
          <td>PIB</td>
          <td><input type="text" name="pib" /></td>
        </tr>
  </tbody>
</table>
 <tr>
      <th align="center" valign="middle"><input align="middle" name="save" type="submit" formaction="/connect.php" formmethod="POST" value="sacuvaj"  /></th>
    </tr>
</form>


sad pokusavam ono
ako su polja prazna da pise da upise brojeve
ako upise slova da upise brojeve
i naravno da ne upisuje u bazu ako ne prodje tu validaciu.
novi sam sa php-om pa je opsta borba.. 2 dana se patim s tim ni nikako da uspem :D
[ plus_minus @ 12.10.2016. 14:19 ] @
Imaš 2 action atributa u form tagu.
Odluči se koji ćeš. Ili number_validation.php ili connect.php

Zatim ... form tag je odmah nakon toga zatvoren.. self-closed..

... method="post" /> ... i to je verovatno glavni razlog zašto nema vrednosti u bazi ..

Sudeći po svemu: stopiraj taj rad koji radiš, stopiraj rad sa PHP-om i bazama, ovladaj HTML-om prvo.


[ sandib @ 12.10.2016. 14:27 ] @
za 2 action atributa sam predpostavio da ne moze pa sam ostavio connect jer on sluzi za povezivanje sa bazom i unos.
unos u bazu radi bez problema. samo sto hocu malo da definisem polja. kopirao sam ova tri jer su ona glavna.
moram da ih napravim tako da naziv objekta mora biti unesen, a maticni i pib da budu brojevi i ako nisu ili ako je polje prazno da ne moze da se unese.
[ MilosDj @ 08.11.2016. 14:38 ] @
Citat:
sandib:
<td><input type="text" name="maticni_broj" id="unos_bojeva"/></td>
$value2 = $_POST["unos_brojeva"];


Ne moze to sto hoces.
Prvo html id mora biti jedinstven u html strani. Drugo html id nema veze sa php-om i $_POST.
Ako hoces da stilizujes sve inpute sa unos_brojeva, koristis class='unos_brojeva'. I to to je sto se tice html id i class.

Ako zelis da grupises inpute u $_POST moras da koristis name atribut!

<input type="text" name="unos_brojeva[maticni]" class="unos_bojeva"/>
<input type="text" name="unos_brojeva[broj1]" class="unos_bojeva"/>
<input type="text" name="unos_brojeva[broj2]" class="unos_bojeva"/>

Onda ide php:

$unos_brojeva = !empty($_POST['unos_brojeva']) ? $_POST['unos_brojeva'] : array();
$unos_brojeva['maticni'],...
[ sandib @ 08.11.2016. 16:55 ] @
resio sam to sto mi je trebalo na ovaj nacin

Code:
    if(empty($_POST['maticni_broj'])) {
            $errorMessage .= "Polje ne može biti prazno";
                } else {
                $maticni_broj = ($_POST["maticni_broj"]);
                if (!preg_match("[0-9]",$maticni_broj)) {
                    $errorMessage = "Dozvoljeni su samo brojevi";
                }
[ Tpojka @ 08.11.2016. 20:37 ] @
Nevjerovatno je na kakav kod su predodredjeni maticni brojevi i PIB-ovi.
Pojesce vam neko podatke iz baze.
Koristite neki FW sa vec dosta ugradjene sigurnosne logike i proucite vise o sigurnosti.
[ sandib @ 08.11.2016. 20:45 ] @
to je neka forma za unos koju koristi samo jedna osoba, niko nema pristup tome. npr ja to sad imam i niko drugi ne zna da to postoji, mislim ta forma.
to je samo da ta "jedna osoba" slucajno ne ukuca slovo umesto broja.
a ti podaci koje je ta osoba unela idu u bazu pa na neke druge stvari
[ mjanjic @ 21.02.2017. 19:38 ] @
Jeste da je malo "kasno", ali za slučaj da neko bude čitao temu u potrazi za odgovorom.

Cilj nam je da što više stvari vezanih za validaciju prebacimo na stranu korisnika, osim kada se zahtevaju osetljive informacije (šifre i sl.).

U konkretnom slučaju treba koristiti JavaScript i "pattern" atribut, što je za JMBG i PIB trivijalno (JMBG uvek ima 13 cifara od kojih je poslednja kontrolna, PIB za pravna lica ima 9 cifara od kojih je poslednja kontrolna, dok PIB za fizička lica ima 13 cifara i jednak je njihovom JMBG).
Za oba broja postoje formule za izračunavanje kontrolne cifre, pa se može i za to uraditi validacija na strani klijenta.
[ VladaSu @ 21.02.2017. 22:10 ] @
Druze... imas vrlo pogresan cilj. Validacije NE SME da se prebacuje na stranu korisnika vec OBAVEZNO MORA da validacija postoji na PHP strani. Ne sme da se prebacuje vec moze paralelno da postoji.
JS uvek moze da se isjljuci ili prepravi i da u JMBG posalje slova i pri upisu u bazu da to bude 0.
Ciljevi su ovako postavljeni:
1. Potpuna validacija podataka na PHP-strani - bitno za sigurnu proveru podataka
2. Potpuna ili delimicna ili bez validacije na korisnikovoj strani - bitno za korisnikov lepsi dozivljaj
[ mjanjic @ 22.02.2017. 05:50 ] @
Izvinjavam se na nepreciznosti, imao sam u vidu problem sa početka teme gde strana nije javno dostupna svima, već samo jednoj osobi, pa sam zato i dao link na kome nisam ni gledao šta je sve odrađeno u php-u.
U opštem slučaju svakako mora postojati na strani servera (logovanje, registracija, pretraživanje, itd.) što se i podrazumeva, ali pri razvoju frontend-a se posmatra kao da je većina stvari vezanih za validaciju na strani korisnika i često se tako implementira u prvim verzijama, a tek kad na red dođe bezbednost/sigurnost podataka...
[ Predrag Supurovic @ 22.02.2017. 08:32 ] @
Baš obrnuto. Kada razvijaš aplikaciju serverski deo razvijaš tako da bude robustan. Validaciju uvek radiš na sloju koji je najbiliži tome što se štiti.

Na primer, ako se radi u upisu u bazu, obavezno baza radi validaciju. Baza mora da obezbedi da ko god da pošalje podatke na upis, validirane ili ne, proveri i dozvoli upis samo podataka koji su ispravni.

Klijentsku validaciju šminkaš tek na kraju. Validacija na klijentu je samo kozmetičke prirode jer to poboljšava "user experience" ali je sa stanovišta sigurnosti, nepotrebna.
[ VladaSu @ 22.02.2017. 08:58 ] @
U PHP-MySQL praksi ne verujem da ces videti da baza radi validaciju npr JMBG broja.
Za to postoje dobri razlozi zasto to niko ne radi.
Skolska baza i baza podataka u praksi se razlikuju.

[ nkrgovic @ 22.02.2017. 09:09 ] @
Citat:
VladaSu: U PHP-MySQL praksi ne verujem da ces videti da baza radi validaciju npr JMBG broja.
Za to postoje dobri razlozi zasto to niko ne radi.
Skolska baza i baza podataka u praksi se razlikuju.

Je'l moze spisak tih dobrih razloga? Za JMBG razumem, ali ja uvek volim da vidim i klasicne constraints na tabelama koje se ticu finansija, a i grantove koji ne daju developeru da uopste uradi neke stvari iz aplikacije - tipa, na tabelama koje imaju finansije nemas fizicki ni DELETE, moze samo SELECT,INSERT,UPDATE. Hoces da ga nema - uveki kolonu JeStorno i koristi je za to. Finansije ne smeju da mogu da se brisu....

Tako da, ako moze objasnjenje zasto je lose imati constraints na kljucnim tabelama, VRLO sam rad da ga cujem.
[ VladaSu @ 22.02.2017. 10:07 ] @
Govorio sam za JMBG i slicne validacije. Ne pricamo o istim validacijama.
Pricamo o validaciji maticnog broja firme ili gradjanina. Ne verujem da pises u MySQL validaciju da JMBG ima 13 brojeva i da su dva poslednja kontrolna i da na osnovu njih proveravas ispravnost kompletnog JMBG-a.
Konkretno sam rekao da nece videti u MySQL validaciju npr JMBG broja i rekao si da razumes zasto.
Ti pricas o validacijama gde dolazi do raspada podataka, npr izbrises neku fakturu ali ne izbrises stavke fakture. Podaci su se da kazem "raspali" i nisu fakncionalni.
Ako neko unese JMBG za 5 broja to je jednostavno neispravan JMBG ali je baza totalno fukncionalana.

Inace davno sam radio finansije.. stavljao sam da mogu da se brisu pod uslovom da su poslednje.

[Ovu poruku je menjao VladaSu dana 22.02.2017. u 11:27 GMT+1]
[ anon115774 @ 22.02.2017. 11:00 ] @
Citat:
VladaSu:
U PHP-MySQL praksi ne verujem da ces videti da baza radi validaciju npr JMBG broja.
Za to postoje dobri razlozi zasto to niko ne radi.
Skolska baza i baza podataka u praksi se razlikuju.


Npr?

Kod mene baza radi kompletnu biznis logiku. Front end ni na jednom jedinom mestu ne radi direktno insert/update/delete (mada u principu delete ne radim nigde) vec iskljucivo poziva stored procedure koje, kada zavrse posao, vrate natrag odgovarajuci exit code i onda u zavisnosti od njega front end zna sta da radi.
[ VladaSu @ 22.02.2017. 11:47 ] @
A kakav sajt je u pitanju? Kolike su ti tabele? Koliko upita imas?
[ anon115774 @ 22.02.2017. 12:03 ] @
Sta je to bitno? Ja to radim uvek i svuda. Bez obzira da li ima 20 upita dnevno ili 20 upita u sekundi.
[ VladaSu @ 22.02.2017. 12:28 ] @
Vrlo je bitno jer mi deluje da ne pricam sa PHP programerom vec .NET ili Oracle a ovo je PHP forum.
[ nkrgovic @ 22.02.2017. 15:17 ] @
Za JMBG je u pravu, jer sam vidjao neispravne JMBG-ove, tj. neispravne po algoritmu - a opet izdate i u upotrebi. Za ostalo... sve je pitanje. Znam PHP programere koji mi tvrde da ORM to sve resava i da ne treba time da se bavi baza, a znam i na sta lice PHP ORM-ovi (offtopic je ovde) i bas zato sto znam kakve gluposti npr. Eloquent ume da nalupeta od upita sam jos ubedjeniji da TREBA da se validira na nivou baze. :D
[ VladaSu @ 22.02.2017. 16:27 ] @
Ne bi trebao neko ko nije PHP programer da savetuje u PHP forumu.
Kako gluposti ORM napravi.. glupost je glupost bez obzira da li je na nivou baze, js ili php-a ili neceg treceg... i ista glupost moze da se napise na bilo kojem nivou. Niko ne garantuje da ce validacija za JMBG na nivou baze biti ispravna....
Naravno sa strane nekoga je admin sve je bajno i sjajno taj teorijski deo...
Da li si znas PHP programera koji ti tvrdi da se to treba resavate ne u ORM nego u bazi?
[ VladaSu @ 22.02.2017. 17:19 ] @
Code (php):

public function rules()
    {
        return array(
            array('title, content', 'required',
                  'message'=>'Please enter a value for {attribute}.'),
        array('username, password', 'required'),
        array('password_repeat', 'required', 'on'=>'register'),
        array('password', 'compare', 'compareAttribute'=>'password_repeat', 'on'=>'register'),
        );
    }
 

Fora je sto recimo u nekom PHP FW jedna kompleksna validacija podataka se resava ovako kako sam neveo.
U bazi bi to bio veliki posao, dosta pisanja sa mogucim bugovima.
Ovde vec ima error message i moze vrlo lako bez ikakvog dodatnog truda da bude na vise jezika.
Kao sto rekoh, pisanje web i desktop aplikacije nije isto. Pisanje PHP i ASP nije isto. MySQL i Access baze nije isto.
Baze sa tri korisnika i baze sa 100.000 korisnika nije isto. 3 i 2000 sql-a u sekundi nije isto.

Ako neko kaze da stored procedura treba u PHP i MySQL ja ne kazem da ne moze vec samo hocu da vidim primer uzivo da je to pristojno funkcionalno na sajtu koji nije seminarski rad.
Ne bih vise jer mislim da je uzaludno sa adminom ili .net programerom pricati kako treba da izgleda php sajt.
[ mjanjic @ 22.02.2017. 17:30 ] @
OK, zahvaljujem na pojašnjenjima, više sam u front-end svetu, a u php-u početnik, ali bitno da je tema živnula ;)

Pogrešno sam se izrazio napisavši da se validacija "prebaci" na stranu klijenta. Htedoh reći da se na backend strani uradi sve što je neophodno od validacije, a potom se sve što je moguće od toga uradi i na strani klijenta ("prebaci" u smislu da se ne kontaktira server pri popunjavanju, osim ako se koristi AJAX), mada, moguće je korišćenjem ajax-a uraditi i backend validaciju svakog elementa posebno u toku popunjavanja forme, mada je za konkretan problem 'overkill', ali se za neke druge slučajeve može primeniti (npr. kod registracije na forumu provera da li je username slobodan).

Bilo bi od koristi nama koji nemamo baš nekog iskustva da se sumiraju potrebni koraci i gde se šta prvo radi.
Što se tiče toga gde se vrši validacija pri upisu u bazu, pretpostavljam da zavisi od toga da li se koristi neki MVC/MVW i sl. model ili određeni FW, a kod većih aplikacija može provera biti dvostruka, i kod kontrolera i kod modela.



Problem su nevalidni JMBG i za njih bi morala da postoji posebna validacija, npr. neki atribut u bazi koji bi se proveravao za svaki nevalidan JMBG koji korisnik unese.
[ VladaSu @ 22.02.2017. 18:25 ] @
Moguce je ajaxom odraditi validaciju svakog polja pojedinacno ali to ima smisla ako zavisi od podataka u bazi kao sto si naveo primer za zauzetost korisnickog imena i to nije overkill jer svaka ovakva sitnica moze da dovede do novog korisinka i moguce zarade.
Cesto se ajaxom radi validacija kompletne forme jer se uglavom samo iskoristi vec postojeca validacija u php. Ne moras da ucitavas novu stranicu.
Kod MVC validacija se najcesce radi u modelu. Nema potrebe da se radi i u kontroleru. U modelu se radi iz razloga jer taj model moze da poziva i API ili neki drugi kontorler ili helper ili nesto drugo i da preskoci validaciju.
Neki to stavljaju u kontroler jer po logici to treba da stoji u kontoleru. Sve je stvar kako koji programer ili FW postavi granicu u razlici izmedju kontorlera ili modela. Videces i ovde na forumu neki su za jednu neki za drugu.
Neko voli robusniji kontroler neko model.
Licno sam za validaciju u modelu iz razloga sto modelu moze da se pridje iz nekog drugog modela ili kontrolera.
Neki FW pored modela i kontrolera imaju jos jednu klasu koja sluzi samo za komunikaciju sa DB-om (neki za to koriste model) i obaveza je ne programirama da svi custom upiti koji se rade nad npr user tabelom budu tu upisani.
Tako sprecimo da neki drugi model poziva neku radnju nad tom tabelom a da mi to ne znamo. To olaksava odrzavanje. Znas tacno gde ti je sta.


Ovo poslednje atribut u bazi i JMBG ne razumem.
[ mjanjic @ 22.02.2017. 19:08 ] @
OK, hvala na pojašnjenjima.


Za JMBG "atribut" u bazi mislio sam na one nevalidne JMBG (kojima kontrolni broj nije ispravan) a koji su ipak nekim ljudima dodeljeni greškom, bilo bi zgodno da postoje negde u bazi (odvojena tabela ili kako već) ako postoji negde dostupan spisak tih JMBG, tako da se pri unošenju nevalidnog JMBG u formu može u toku validacije proveriti da li je u pitanju jedan od takvih JMBG.

U tom slučaju prvi korak validacije samo na strani klijenta nije moguć, već se u slučaju unošenja neispravnog JMBG mora proveriti da li je to jedan od tih problematičnih (umesto da se samo obavesti korisnik da je uneo nevalidan JMBG). Takođe, ako se vrši unos, čak i ako je ukucan ispravan JMBG, može se odmah proveriti da li je već ranije unet u bazu da se ne bi unosili ostali podaci.



Mogao bi za unos JMBG praktično da se uradi neki dijagram sekvenci sa svim mogućim slučajevima.


Možda bi mogući scenariji pri unosu JMBG bili sledeći:

1. korisnik unosi JMBG
2.1. ako je validan (provera na strani klijenta), zahteva se od servera podatak da li takav već postoji u bazi
2.1.1. ako postoji u bazi, korisnik se obaveštava da taj podatak već postoji i forma može da se resetuje (ili uradi nešto drugo, zavisi od potreba klijenta)
2.1.2. ako ne postoji u bazi, korisnik dalje nastavlja unos ostalih podataka za taj JMBG
2.2. ako nije validan, proverava se da li je takav na spisku greškom dodeljenih nevalidnih JMBG (tabela u bazi ili neki drugi izvor?)
2.2.1. ako je na takvom spisku, korisnik dalje nastavlja unos ostalih podataka vezanih za JMBG
2.2.2. ako nije na takvom spisku, korisnik se obaveštava da taj JMBG nije validan

Da li je ovo u redu (odnosi se samo na to šta se može desiti pri završetku unosa samo JMBG, ne i ostalih podataka) ili bi iskusan developer imao bolji i/ili efikasniji pristup?



Na prvi pogled bi se reklo da je problem prost, a kad ono...
Čak imamo problem da se pri kucanju JMBG mogu desiti višestruke greške tako da JMBG bude ispravan (provera kontrolnog broja), ali da u stvarnosti nikome nije dodeljen. Ne vidim kako ovo rešiti, osim ako bi se možda vršila dodatna validacija upitom u jedinstveni birački spisak (sad proverih stranu za ručnu proveru, koriste captcha).

Ali, ovo nije vezano striktno za PHP, nego generalno za predviđanje svih mogućih scenarija pri unosu JMBG i ostalih podataka.
[ VladaSu @ 22.02.2017. 20:06 ] @
1. Proveris sve na JS strani sta je moguce tj da li je validan broj, format (kontrolni broj ne proveravas).
2. Ajaxom proveris, (ne moras ovaj korak i to zavisi od same aplikacije i zahteva, ne vidim neki poseban razlog za ovaj korak ali moze).
1. Opet da li je ispravan po formatu i kontrolnom broju i ako nije onda proveris da li je u listi neispravnih. Ovaj korak ide prvi jer ako nije ispravan ne zahteva nikakav dodatan upit ka bazi
2. Da li je zauzet (ovaj ide drugi korak jer je uvek upit ka bazi)
3. Submit ponovis ponovo proveru koja je u ajax delu.

Ono sto si ti preskocio je provera na php delu da li je broj validan po kontrolnom broju.

U slucaju da nemas spisak brojeva koji nisu validni onda ti samo presotaje da proveris sa kontrolnim brojem pa u bazi da li postoji i ako nije validan i ne postoji u bazi onda ga obavestis da broj nije validan i da proveri tj potvrdi da ima jmbg koji nije validan.

Trece opcija za sluca da nemas spisak koji nisu validni nemoj nista proveravas tako striktno vec da li su brojevi i nisu slova i da svako unosi na svoju odgovornost jer prakticno nemas uslova za striktnu proveru.
Provera u biracki spisak nije potupna jer deca nisu u birackom spisku a imaju jmbg a biracki sposkovi su nam katastrofalni :)

[Ovu poruku je menjao VladaSu dana 22.02.2017. u 22:04 GMT+1]
[ Shadowed @ 22.02.2017. 21:33 ] @
Citat:
VladaSu: Ne bih vise jer mislim da je uzaludno sa adminom ili .net programerom pricati kako treba da izgleda php sajt.

Nema to veze. Ja sam .NET programer pa sam vise za ono sto si ti zastupao u toj prici.
Doduse, ja sam vise "spram projekta i resenje" ali generalno smatram da biznis logika treba biti u sluju biznis logike (jelde).
Ako gledamo kao generalni princip, smatram da baza treba da ima contraint-e koji se ticu strukture podataka (tipovi kolona, relacije FK-PK i sl.) ali BL constraint (npr. godina mora biti izmedju 1900 i trenutne) je posao BL sloja.
I to je softverska arhitektura, nije vezana za jezik. Samo je to sto je nkrgovic pricao cesca pojava u enterprise projektima a oni su cesci u .NET (i Java) svetu pa si zato povezao sa tim jezicima
[ mjanjic @ 22.02.2017. 22:39 ] @
Citat:
VladaSu:
Ono sto si ti preskocio je provera na php delu da li je broj validan po kontrolnom broju.
[Ovu poruku je menjao VladaSu dana 22.02.2017. u 22:04 GMT+1]

Nisam još dotle ni stigao, ono je sve bilo na strani klijenta, uz AJAX prema serveru gde je neophodan.


A to za biračke spiskove zaboravih da tu nisu maloletni građani.
Postoji provera validnosti JMBG na sajtu http://jmbg.brmbrm.com/ ali mislim da ne proverava da li je nekome dodeljen taj broj.

Nego, ako se kojim slučajem JMBG ukine kao u Hrvatskoj, gde se koristi potpuno slučajan broj, šta ćemo onda sa validacijom?
[ plus_minus @ 22.02.2017. 23:20 ] @
Citat:
Nego, ako se kojim slučajem JMBG ukine kao u Hrvatskoj, gde se koristi potpuno slučajan broj, šta ćemo onda sa validacijom?


Uvek, staro dobro :
Code (php):

 if ( $jmbg_field_present === true ) { MY_ABSTRACT_CLASS_NAME::validate_jmbg(); }
 


uz else naravno ...

Elem, ispravno pitanje bi bilo: "Šta ćemo uopšte sa samom aplikacijom, formom .. ?"
[ nkrgovic @ 23.02.2017. 10:37 ] @
Citat:
VladaSu:
Ne bi trebao neko ko nije PHP programer da savetuje u PHP forumu.
Kako gluposti ORM napravi.. glupost je glupost bez obzira da li je na nivou baze, js ili php-a ili neceg treceg... i ista glupost moze da se napise na bilo kojem nivou. Niko ne garantuje da ce validacija za JMBG na nivou baze biti ispravna....
Naravno sa strane nekoga je admin sve je bajno i sjajno taj teorijski deo...
Da li si znas PHP programera koji ti tvrdi da se to treba resavate ne u ORM nego u bazi?

U nedostatku argumenata prelazimo na ad hominem, zanimljivo... :) Da, znam gomilu razumnih programera.

Za ostale: Ako imate projekat koji naruciocu posla deluje bitno (njegov core business) ili ako imate projekat koji ima regulativu (finansije je uvek imaju) - a realno obicno su oba u pitanju, neke stvari se verifikuju VISE PUTA. Imate verifikaciju na user interfejsu da smanjite sum, imate neke provere na nivou servera, imate proveru logike na nivou aplikacije, imate i analizu komponenti u frameworku koje proveravaju sve sto ide u bazu (nevezano za ovo, ali npr. kao neki input sanitization), onda imate constraints na bazi, a onda imate i utegnute privilegije. I onda na sve to imate i testove koji pre deploy-a verifikuju da svaki od tih pojedinacnih provera zapravo i radi svoj posao. :D

Neke stvari, finansije su ocigledan primer, su veliki problem ako se ne slazu ili ako imaju problema u konzistenciji podataka. Svaki kod ima poneki propust i ne zelite da vas neko juri zbog vaseg - ili tudjeg. Zato verifikacije radite vise puta. Neke stvari je prakticnije verifikovati samo u kodu - jer lakse skalira horiznontalno i manje "boli" sistem, ali za proveru kriticnih se uvek nadje resursa.
[ Predrag Supurovic @ 23.02.2017. 11:29 ] @
Citat:
VladaSu:
U PHP-MySQL praksi ne verujem da ces videti da baza radi validaciju npr JMBG broja.


Baza i ne treba da radi tu validaciju jer je ona deo biznis logike a ne logiek baze. Baza treba, na primer, da obezbedi da ne moze isti JMBG da se upiše za dve osobe i slicno.

Validacija uvek treba da se radi u onom sloju kog se dati podatak tiče. To znači da slojevi iznad ne moraju da se bave njome a naročito, ako ima više različitih slojeva koji se oslanjaju na sloj koji radi validaciju validacija će za sve njih bita ista.

To ne znači da viši slojevi ne smeju da rade istu validaciju za svoj račun, ali to nije neophodno i radi se samo radi boljeg "user experience". Na primer, uvek je korisniku zgodnije ako se validacija uradi JavaScript-om odmah već prilikom ukucavanja podatka, nego da popuni ceo obrazac, posalje ga i tek tada dobije poruke šta sve nije ispravno uneo.

Čak i tada, bolje je da donji sloj obezbedi API preko koga gornji sloj može da se posluži istom onom validacijom koju radi donji sloj a ne da pravi sopstvenu logiku za validiranje. Tako se obezbeđuje da se validaciajuvek radi na isti način i ako se menja nešto u njenoj logici, menja se na jednom mestu.



[ VladaSu @ 23.02.2017. 12:16 ] @
@Predraze.. 300% se slazem sa tobom nego ima ko nikada nije programirao i dodje na forum i kaze da to tako mora da se radi.

@nkrgovic
Vidi, iskreno, ja sam tek sada pogledao sa cime se ti bavis ali po tvojim pisanjima sam ranije tacno zakljucio da si ili administrator ili .NET ili nesto slicno a ne PHP.
Zasto sam to zakljucio? Zato sto jedan PHP programer ne bi tako nesto napisao.

Vidim da si radio u limundu. Ni oni ni za jedan njihov sajt ne rade takve valildacije na nivou baze. Pitaj B. :)

Ne mogu da ti iznosim argumente zasto to ne valja.
To je kao da objasnjavam nekome da ne valja ici u prodavnicu avionom vec treba ici autom a da taj nije video ni auto ni avio ali je citao da mnogo manje ljudi pogine u avionom, da je prevoz avionom jeftiniji i sigurniji i mnogo brzi.
Teorijski je to tacno da je prevoz avionom jeftiniji, mnogo brzi i sigurniji ali do prodavnice 2 ulice nize ce da te kosta vise nego autom i bice sporiji i verovatno ces naleteti na prvu zgradu.
I onda mi jos on kaze da zna puno razumnih ljudi koji u prodavnicu idu avionom. I stvarno ima ljudi koji u prodanicu idu avionom ali njih zabole da li je to isplativo, da li to vredi, da li je prakticno vec idu da se malo pros*ravaju.

Zasto npr Mangento koji je napisan ekstra skolski po striktnim pravilima to ne radi?
Zasto ne rade blic, polovniautomobili, mojauto, kupujemprodajem, limundo, b92, winwin, ES.. ma ni jedan domaci sajt u prvih 100.
Verovatno postoji razlog....


Molim te, prekljinem te, molim te.... :) posto znas puno razumnih PHP programera koji tako rade i posto znas da tako treba da se radi onda mooolim te daj link do jednog takvog sajta. Samo jedan sajt sto je neko iz te gomile PHP programera uradio sajt. Molim te i prekljinem i javno cu da ti se izivinem!

Stvarno i iskreno bih voleo da vidim i to ne iz razloga da bi mi ti nesto dokazao vec hocu da dobijem priliku da se edukujem. Bez podcenjivanja i prozivanja i dokazivanja vec iskreno zbog rada na sebi.
Mozda posle 20 godina programiranja vreme me gazi i ne radim dovoljno na sebi i imam neko zatucano staro razmisljanje.

Inace... finansije.... znam kako izgleda kod u par banaka i cak ni tamo nije tako kako ti kazes. Ni priblizno!
[ anon115774 @ 23.02.2017. 13:07 ] @
Meni je jednom davno neko rekao: "Sve moze ali nikad nemoj da dozvolis da djubre udje u bazu."

Kada sam malo razmislio shvatio sam da to itekako ima smisla. Od tada se drzim toga bez izuzetka.

Dakle, ako je neko polje u bazi definisano kao integer onda tu moze da se upise samo integer. Ako bi se nekako upisalo bilo sta sem toga nastao bi haos. Ugradjeni mehanizmi same baze omogucuju ovakvu proveru i odbacice sve sto nije integer.

Ista stvar se primenjuje i na polje koje je definisano kao JMBG samo sto baza u ovom slucaju nema ugradjene mehanizme za to vec korisnik sam mora da napise. Ja uvek polazim od toga da je baza prva (ili poslednja - zavisi od kog ugla se gleda) linija odbrane i ne moze se zaobici.

Kada kazem "zaobici" mislim na neke druge procese/servise itd. Zato uvek i bez izuzetka napravim stored proceduru i sve te stvari se obavljaju preko procedure. Ukoliko dodje do promene logike samo udjem i promenim proceduru i ne moram da brinem da li je mozda jos negde ostao stari kod. Takodje, nekad je potrebno radi same validacije da se napravi nekoliko ozbiljnih upita u bazu da bi se dobio rezultat validacije. Uvek gledam da je bolje da to uradi sama baza nego neki back-end.

Neko je pitao cime se bavim... pa ja sam izmedju ostalog MSSQL programer na enterprise grade sistemima (banke, telco itd). To u prevodu znaci tabele sa nekoliko hiljada kolona i/ili, tabele sa nekoliko stotina miliona redova, tabele sa nekoliko stotina gigabajta... itd. U velikom broju slucajeva se desava da razliciti sistemi pristupaju istoj bazi i pisu i brisu. Bilo bi potpuno ludilo da svaki od tih sistema vodi racuna o zajednickoj biznis logici. Na primer, ako bi svaki od tih sistema trebao da radi validaciju JMBG-a tu bi bio haos ako treba da se izvrsi neka promena.

A osim toga se bavim i php/mysql kombinacijama. Elem... a kakve to veze ima da li se neko bavi php-om ili .net-om? U cemu je razlika? Znaci, ako se ja bavim velikim sistemima onda treba da se primenjuje najbolja praksa a ako se radi u php-u onda je nebitno i moze da radi ko kako hoce?
[ VladaSu @ 23.02.2017. 14:06 ] @
@informer
"Meni je jednom davno neko rekao: "Sve moze ali nikad nemoj da dozvolis da djubre udje u bazu.""
Meni su na svakom PHP poslu rekli: "Ono sto si ucio na casovima o bazama podataka to ovde ne vazi"
Da krenem od tabele sa nekoliko hiljada kolona. To je ozbiljna greska u MySQL kada se prave sajtovi. VRLO OZBILJNA GRESKA. Cim neki PHP programer napravi takvu tabelu on ne moze da dobije posao.
To je ovde najlosija praksa iz razloga sto ce load stranice da bude 10 umesto 0.5 sekundi. To nekoj radnici na salteru u banci ne znaci nista. Ona tamo sedi 8-9 sati.
Jednom sajtu znaci puno jer ce ga google baciti na desetu stranicu a to automatski znaci 99% manje poseta i 99% manje para. I tih 1% korisnika koji dodju na sajt posle 5 sekundi ce da odu na drugi.
Pitas u cemu je razlika. Razlika je da ce ti neki sajt zaradjivati ili nece. Razlika je ogromna.
U MySQL tabele sa stotinama miliona redova takodje vrlo losa praksa u MySQL. U MySQL tabela sa preko 10 miliona redova se razbija na jos tabela a cesto i na vise baza.
Mnogi podaci na webu se kesiraju dok u bankama ne a nad kesiranim podacima mysql ne moze da radi vec mora uvek da pristupa podacima u bazi.
Podaci se kesiraju jer je opet problem brzina a brzina je novac. Sve se zrtvuje zarad brzine sajta a baza podataka je uvek usko grlo.
Raditti validaciju JMBG broja u MySQL za neki websajt je suludo jer to kosta brzine a samim tim poseta korisnika i novca. Brzina sajta je direktno vezana za novac. Mozes sve super da imas uradjeno na sajtu ali ako je spor on nece donositi profit.
Zato sam i rekao da sam siguran da se ne bavis php i mysql programiranjem vec desktop i bio sam upravu.
To sto je u banci najbolja praksa na webu je najlosija.
Mi imamo servere ciji zakup pojedinacno mesecno kosta vise od 10.000$.. Ne secam se tacno kakve ali neke lude masine. Citav sajt nam je razdvojen. Npr registraciju korisnika vrsi jedan server. Unos oglasa vrsi drugi server, poruke treci.
Cak su nam neke tabele podeljene na vise servera pa imamo "workere" koji citaju odredjeni SQL sa svih tih servera pa spajamo podatke u kodu. I mi se zaglavljujemo na MySQL. Za neke stvari koristimo baze koje su same tabele bez relacija kao NoSQL ili Mongo.
Tabela za password nam ima dve kolone user_id, password, za email, user_id i email. Na glavu user tabelu ne smes da nakacis nikakvu kolonu. Pogovo tipa text koja dosta usporova.
Kada bi neko stavio na user tabelu prodecuru koja proverava JMBG usporio bi sajt i dobio bi otkaz. Malo karikiram ali u firmi ima vise PHP programera nego komplet radnika u banci.
Sajt nam se ucitava za 1,5 sekundi i trudimo se da se ucita ispod jedne sekunde.
A onda kada krene marketing tim da osvaja novo trziste pa skoci load servera sa 10 na 90% a ti vidis da je neko stavio takvu validaciju i nije kesirao podatke. Ubijes se.

Druga stvar... To sto ti radis sa PHP to je zato sto nisi PHP programer vec to radis iz hobija ali ja bih voleo da mi neko kaze u prvih 1000 PHP sajtova u Srbiji da je jedan uradjen tako.
Pricate kao da svi tako rade a ja tvrdim da niko u PHP ne radi tako. Mozda .NET programer koji se igra malo sa PHP a vidim da ima i .NET programera koji ne bi tako radili. Siguran sam da nema PHP programera koji bi tako radio.
I sami ste priznali da niste PHP programeri.


[ VladaSu @ 23.02.2017. 14:10 ] @
Zasto sam skontao da niste PHP programeri tj web?
Stvar je u uglu gledanja. Da li da to bude perfektno lepo, skolski i logicki u funkcionalno ili da li da zaradjuje.

Kada vec pricate da se to tako vrlo uobicajno radi u PHP MySQL ja samo trazim da mi date jedan konkretan primer. Samo jedan primer a da nije seminarski rad nekog studenta.
[ Shadowed @ 23.02.2017. 14:17 ] @
Citat:
VladaSu:Teorijski je to tacno da je prevoz avionom jeftiniji, mnogo brzi i sigurniji ali do prodavnice 2 ulice nize ce da te kosta vise nego autom i bice sporiji i verovatno ces naleteti na prvu zgradu.
I onda mi jos on kaze da zna puno razumnih ljudi koji u prodavnicu idu avionom. I stvarno ima ljudi koji u prodanicu idu avionom ali njih zabole da li je to isplativo, da li to vredi, da li je prakticno vec idu da se malo pros*ravaju.


Tako je, samo sto je totalno nebitno da li vozac aviona ili automobila prica srpski, engleski ili nemacki :)
Razlika je u daljini putovanja.
Iliti, vraceno na nasu temu, razlika je u velicini/slozenosti projekta. Po tome sto ti pises, ispada da se ili PHP ne koristi za velike/slozene sisteme ili zbog nekog "to-se-tako-u-php-u-ne-radi-nika" razloga ne treba u php-u raditi drugaciju arhitekturu iako bi realno trebalo. A zasto PHP programeri to tako (ne) rade nikad (mada bih pre rekao mnogo redje) cu da precutim da ne ispadne da flame-ujem i ne ode previse u advocacy. A i da ne trigger-ujem plus_minus-a :P

Ukratko, ono sto hocu da kazem je da ono o cemu pricamo nije tema programskih jezika vec arhitekture IS-a a da se implementacija moze uraditi u raznim tehnologijama/jezicima (u nekim lakse, u nekim teze).
[ nkrgovic @ 23.02.2017. 14:23 ] @
Ja bi ama bas stvarno voleo da smem da pricam, pa da ti ispricam koliko ima na Limundo bazi provera, na koliko su slojeva, sta se radi SAMO kroz stored procedure i koliko sam vremena kao neko kome je odgovornost bila DB server provero sa programerima pokusavajuci da napravimo da bas na primer finansijske transakcije budu verifikovane na vise nivoa. Znas kako se zavrsi na kraju? Tako sto je mom tamosnjem tehnickom direktoru, inace developeru koji je od pocetka u Limundu, lakse da ode do banke i uplati 100 dinara na svoj racun za testiranje, nego da proba da to upise u bazu na ruke. E, toliko ima nivoa provera i constraint-a.
[ plague @ 23.02.2017. 14:29 ] @
Citat:
Neko je pitao cime se bavim... pa ja sam izmedju ostalog MSSQL programer na enterprise grade sistemima (banke, telco itd). To u prevodu znaci tabele sa nekoliko hiljada kolona i/ili, tabele sa nekoliko stotina miliona redova, tabele sa nekoliko stotina gigabajta... itd. U velikom broju slucajeva se desava da razliciti sistemi pristupaju istoj bazi i pisu i brisu. Bilo bi potpuno ludilo da svaki od tih sistema vodi racuna o zajednickoj biznis logici. Na primer, ako bi svaki od tih sistema trebao da radi validaciju JMBG-a tu bi bio haos ako treba da se izvrsi neka promena.

Losa arhitektura. :)
Baza sluzi za cuvanje podataka i to joj je primarna svrha. To sto mozes raditi i druge stvari u njoj je "side-effect" koji je proistekao usled "monopola":
Imas mnogo dobar proizvod koji radi A i mnogo je dobar kada se koristi zajedno sa B, C i D. Hajde da napravimo X koji pokusava da radi B, C, D i damo zajedno sa A.

Razliciti delovi sistema ne treba da pristupaju direktno bazi nego da koriste servise koji poseduju bazni model.
Ti servisi sarze svu logiku i oni su pisani u visim jezicima gde je mnogo lakse koristiti stvari kao sto su abstrakcija, paralelizam, testove, integraciju sa drugim sistemima pisanim na drugim tehnologijama, horizontalnu skalabilnost, verzionisanje, bibloteke, kolaboraciju pa cak i nesto osnovno kao sto je Refactoring koda itd.

Kao neko ko je imao iskustva sa DB heavy projektima, mogu da kazem da razlozi "za" nikako ne mogu da opravdaju "protiv".
[ VladaSu @ 23.02.2017. 14:34 ] @
Zasto se ne javi ni jedan PHP programer koji tako radi?
Ja sam radio VB 4-5-6, 4-5 godina pa onda C#.NET 3-4 godine i 10 godina PHP.
Radio sam stored procedure na MSSQL, Firebird i to je tamo imalo sasvrsenog smisla iako se nisam cesto susretao da neko tako radi. Ali je barem imalo smisla i moglo se bez ikakvih posledica tako raditi.

U PHP je drugacija prica. Takav rad kasnije moze da ima velike probleme.

Ono sta zelim je da vidim neki ozbiljan sajt tako napisan kada vi .NET programeri tvrdite da to nije retkost. Ne bi trebao da vam je problem da ostavite desetine linkova.
Ako vec tvrdite da je neki sajt tako napisan onda sta je problem ostaviti linkove ka tim sajtovima?
Evo ja cu ostaviti linkove sajova koji sigurno nisu tako napisani.
limundo, kupindo, kupujemprodajem, blic, polovniautomobili, mojauto, b92.
Na internetu ima hiljade i hiljade PHP CMS-ova tipa wordpress, opencart, mangento ... dajte mi link do barem jednog CMS-a koji je tako napisan.. source kod mozemo da vidimo.

Fora je sto necete naci ni jedan CMS, ni jedan kod (sme primera kako bi to moglo da se uradi) i necete naci ni jedan ozbiljan sajt da tako radi.

Vi meni pricate kako bi trebalo teorijski da radi a ja pricam kako to prakticno rade. Vi tvrdite da se i prakticno tako radi u PHP pa molim link, primer da vidim. Internet je pun kodova ali ja ne mogu da nadjem ni jedan kakav vi opisujete a po vama trebao bih da imam problem
da nadjem kod i sajt kakav ja opisujem.
Zar to nije cudno????
[ svepomalo @ 23.02.2017. 14:46 ] @
A kako bi uopste izgledala validacija JMBG-a u bazi?
Znam kako bih je napisao u php-u ali mi nije jasno u bazi, function, trigger, stored procedure?
Jel se ovde validacija na strani baze podrazumeva da raw input upucuas bazu pa da validiras ili nesto drugo?
Ako moze neki primer ili ja nesto nisam skontao kako treba iz cele ove prepiske.
[ nkrgovic @ 23.02.2017. 15:05 ] @
A ja ti kazem da limundo i kupindo jesu dobrim delom tako pisani i da je ziva muka promeniti bilo sta vezano za neke delove koda, a da je prakticno nemoguce napraviti izmene tipa "da nestanu finansijske transakcije" ili nesto slicno. I da, to je namerno tako.

I mi svi i dalje cekamo da nas prosvetlis zasto je lose imati vise nivoa validacije za kriticne podatke i sta je tu toliko specificno u PHP-u da je nemoguce imati tako nesto? Koje su to posledice, konkretno, na PHP ako postoji constraint u bazi, ili ako koristis prepared statement, koji dalje vuce stored procedure, a da pri tom samo ta procedura ima grantovano da radi sa nekim tabelama, tj. da i ne mozes direktno iz svog koda to da radis? Zasto je to OK u Java-i a nije OK u PHP-u?
[ Predrag Supurovic @ 23.02.2017. 15:56 ] @
Citat:
Informer:
Ista stvar se primenjuje i na polje koje je definisano kao JMBG samo sto baza u ovom slucaju nema ugradjene mehanizme za to vec korisnik sam mora da napise. Ja uvek polazim od toga da je baza prva (ili poslednja - zavisi od kog ugla se gleda) linija odbrane i ne moze se zaobici.

Kada kazem "zaobici" mislim na neke druge procese/servise itd. Zato uvek i bez izuzetka napravim stored proceduru i sve te stvari se obavljaju preko procedure. Ukoliko dodje do promene logike samo udjem i promenim proceduru i ne moram da brinem da li je mozda jos negde ostao stari kod. Takodje, nekad je potrebno radi same validacije da se napravi nekoliko ozbiljnih upita u bazu da bi se dobio rezultat validacije. Uvek gledam da je bolje da to uradi sama baza nego neki back-end.


Ovaj tvoj pristup je jedan način gledanja na stvari, nije neispravan, ali se sve ređe primenjuje, iz razloga nepraktičnosti. Može da ima smisla ako se radi o nekoj izuzetno pipavoj optimizacijipa se hvata za svaku slamku da se brže dobije rezultat.

U praksi se pokazalo da je bolje bazu gledati kao skladište podataka (storage). Kao takva ona ne treba da zna ništa o svrsi podataka sa kojima radi već samo da skladišti podatke. Poneko čak na nivo baze ne implementira ni referencijalni integritet, madaja ne bihišao baš toliko daleko.

Kada se tako gleda, baza ne treba da o JMBG zna ništa više nego da je to niz znakova (ili broj, zavisi kako to ko definiše). Ne može da validira dali je JMBG ispravan, već samo da li je odgovarajućeg tipa i da li se uklapa u pravila referencijalnog inegriteta. I ništa više od toga.

Sledeći stvar je da bazi ne može neko tek tako da pristupa, već to mora da radi preko sloja za rad sa podacima (Data Layer). DataLayer je taj koji može da implemetira dodatna pravila, pa i da impementira validaciju JMBG. U tom kontekstu, potpuno je pogrešna postavka da dve apliakciej mogu da pristupaju bazi. To se nikako ne radi, dve apliakciej mogu da pristupaju istom sloju podataka (mada i to uslovno jer je i to najčešće previše nizak nivo pristupa).

Sloj podataka i dalje ne zna sve o podacima sa kojima radi. Može na primer da zna koji je tačan format JMBG i da radi tu vrstu valdiaciej ali ne zna čemu JMBG služi u širem kontekstu. TO radi poslovni sloj (Business Layer). Poslovni sloj zna čemu podaci služe,kakvi su njihovi odnosi i šta sa njiam može da se radi. On može da radi i validacije koje su znatno višeg nivoa (tipa, ovaj proizvod može da se poručuje samo ako ga ima na stanju).

Ako se vratimo na priču o dve apliakcije koje treba da pristupajusitim pdacima, naslućuje se da bi u stvari te apliakcije trebalo da pristupaju poslovnom sloju jer samo on obezbeđuje primenu i svih poslovnih pravila. Međutim tom sloju se ne pristupa direktno već preko aplikativnog interfejsa.

Namena apliaktivnog interfejsa je da napravi izolaciju izmedju serverske aplikacije i klijenata u svakom smislu: obezbedjuje se nezavisnost od platforme, univerzalnost podataka i slično). U praksi to su REST, SOAP i slični protokoli.

Ovo nije teorija, ovako se radi u praksi iz mnogo razloga. I čak se ne radi u ovako malo slojeva kako sam opisao nego to ume da budo mnogo finije razrađeno. Naravno, ovako postavljen sistem je složen i može da postane nepraktičan kada se radi neka jednostavna apliakcija. Tada se navedeni slojevi spajaju i pojednostavljuju. Za jednostavnu PHP apliakciju, čaki neki CMS, može sve da se svede na bazu i podatkovno-poslovni sloj i eventualno api sloj ako treba vise apliakcija da deli iste podatke.

U praksi, jednostava PHP apliakcija može da ima slojeve:

- baza, koja samo implementira referencijalni integriteti validacije tipova;

- podatkovno-poslovni sloj, koji čini skup klasa a koej mogu da predstavljaju svaku tabelu pojedinačno ili provarene skupove tabela (na primer možeš daimaš klasu za zaglavlje porudžine i klasu za stavke porudžbine amožeš da imaš jedna objekat prudžbina koji su sebi sadrži zaglavljei stavke). Ove klase su zadužene i za sve validacije na nivou poslovnih pravila. To znači da ako ti treba neki podatak izbaze NIKADA nećeš pristupati bazi nego ćeš insancirati odgovarajući objekat koji predstavlja podatak oji ti treba i preko tog objekta ćeščitati ili upisivati podatke u bazu. U praksi to znači da se svi SQL upiti nalaze u ovom sloju. Gornji slojevi ne vide ni S od SQL-a. Umesto toga oni pozivaju metode klasa i daju im samo parametre na osnovu kojih će biti izgrađeni SQL upiti. Čaki ako su opdatkovni i poslovni sloj razdvojeni, poslovni sloj ne koriti SQL, i on se za sve manipulaciej sa bazompodataka obraća podatkovnom sloju koji gradi SQL-ove po potrebi.

- korisnički intefejs, koji se bavi prikazivanjem podataka, prikupljanjem podataka za upis u bazu isličnim poslovima akoji se obraća poslovno-podatkovnom slovu za sve manipulaciej sa podacima (čitanje, validacije, upis, brisanje itd...)

- obično se napravii API sloj, koji omogućava da i neke druga apliakcije mogu da koriste podatke iz baze a taj API sloj se takođe za sve manipulacije sa podacima obraća poslovno-podatkovnom sloju.


Ovakva organizacija omogućava da kad god treba nešto da se implementira u aplikaciji, tačno se zna gde se to radi, a ako treba nešto da se menja u funkcionalnosti takođe se zna gde se to radi i takva promena je odmah primenjena u svim drugim delovima apliakcije. Ne može da se desi da moraš na dva mesta da implementiraš nekufunkcinansot (na priemr validaciju) pa da, ako je potrebno da se promeni način validacije, moraš na oba mesta to da menjaš. Svaka validacija treba da se radi samo na jendom mestu, u onom sloju na koji se ta validacija odnosi. I nikada, niko ne sme da zaobiđe neki sloj, jer ako to uradi narušava integritet aplikacije.


Kao što vidiš, striktna zabrana "zaobilaženja" se ne odnosi samo na bazu, kako ti praktikuješ, već se odnosi i na svaki drugi sloj apliakcije. Ako je neko sloj zadužen za neki posao, niko ne sme da ga zaobiđe i da taj posao uradi drugačije.
[ plus_minus @ 23.02.2017. 16:08 ] @
Ma ja mislim da je red da se zabatali i PDO i sav ctype arsenal i sve filter_input varijacije i sve što PHP nudi od mb_* f-ja i sve u *sql d se čuka...
Pa mis'im ako se već dodatno plaća rad sql servera, što da ga štedimo, hebi ga.. kad može i kad je to super multi-level praxa/security.

ps: this was hard-core irony.
[ Predrag Supurovic @ 23.02.2017. 16:20 ] @
Citat:
VladaSu:
Da krenem od tabele sa nekoliko hiljada kolona. To je ozbiljna greska u MySQL kada se prave sajtovi. VRLO OZBILJNA GRESKA. Cim neki PHP programer napravi takvu tabelu on ne moze da dobije posao.
To je ovde najlosija praksa iz razloga sto ce load stranice da bude 10 umesto 0.5 sekundi.


Pretpostavljam da bi Bogdan Kecman terbalo da se umeša i da objasni iz ugla MySQL-a kako se stvari odvijaju.

Verujem da bi MYSQL serveru moglo da smeta ako tabela ima mnogo kolona i da bi pristup podacima mogao da bude usporen. Medjutim, sa stanovista citanja podataka uopste, to i nije tako bitno, jer neces ti nikad citati sve te kolone nego samo one koje ti trebaju. Ja svaako to ne bih karakterisao kao ozbiljne greske nego kao slabiju optimizaciju. U vecini primena to uopste ne bi bilo bitno a u onim gde je bitno, mora se voditi racuna o jos mnogo toga.

Slazem se da je dobra praksa raspodeljivati podatke u vise tabela kad god je to prakticno. Medjutm treba imati u vidu da i JOIN ima svoju cenu u performansama. Kad bismo otičli ukrajnost onda bi svaka kolona dobiaj svoju tabelu a ipak se to tako ne radi je rni to niej praktično. Terbanaći neku meru, razdvajati podatke u tabele ako za timim atvarne potrebe i ni u tome ne treba preterivati.

Citat:

U MySQL tabele sa stotinama miliona redova takodje vrlo losa praksa u MySQL. U MySQL tabela sa preko 10 miliona redova se razbija na jos tabela a cesto i na vise baza.


Ih kad radiš sa milionima slogova to je sasvim neka druga dimenzija i mnog se tu problema javlja koje treba rešavati. Ali i to je opet, samo pitanje optimizacije.

Citat:

Raditi validaciju JMBG broja u MySQL za neki websajt je suludo jer to kosta brzine a samim tim poseta korisnika i novca. Brzina sajta je direktno vezana za novac. Mozes sve super da imas uradjeno na sajtu ali ako je spor on nece donositi profit.


Hm.. validacija JMBG se radi samo kada se upisuje podatak u tabeli u to se obicno ne radi sa velikom kolicinom podataka odjednom nego jedan po jedan slog. Tu brzine validacije nije bitna. A kada se podaci citaju, validacija se uopste i ne aktivira te i nema nikakav uticaj na brzinu izdvajanja.

Citat:

Zato sam i rekao da sam siguran da se ne bavis php i mysql programiranjem vec desktop i bio sam upravu.


Ne znam koliko se srećeš sa pisanjem desktop apliakcija ali sve više je to slično razvoju za web. Savrmeni alati čak više i ne omogućavaju neke tehnike programiranja iprogramske alate koji su bile karakteristični za desktop i davale mu snagu. Sve se to sad svodi na webolik pristup (ne u vizelnom, nego u programerskom smislu).

Citat:

Tabela za password nam ima dve kolone user_id, password, za email, user_id i email. Na glavu user tabelu ne smes da nakacis nikakvu kolonu. Pogovo tipa text koja dosta usporova.
Kada bi neko stavio na user tabelu prodecuru koja proverava JMBG usporio bi sajt i dobio bi otkaz.


Opet ponavljam meni ovo zvuči vrlo čudno, ili je ta vaša apliakcija nekako čudno isprojektovana kada validacija JMBG ima tako negativan uticaj na akcije koje sa tom validacijom i nemju mnogo dodira. Na stranu što mi je čudno da je apliakcija koja, ako dobro razumem radi vrlo osetljiv intenzivan bankarski posao, uopšte radi na PHP. Volim ja PHP i rado ga korsitim, ali mislim da je on neadekvatan za tu vrstu posla.

Razumljivo je da ako se radi alikacija koja obarđuje ogroman broj podataka,ogroman broj istvormenih obrada ilsičneintenzivne polsove, mora da se pegla gde god se može, pa i da se odskače od dobre prakse, da se hvataju krivine i prečice, ali to ipak treba gledati upravo tako, kao izuzetak koji potvrđuje pravilo.

[ mjanjic @ 23.02.2017. 16:21 ] @
Uze mi 'Shadowed' reč, hteo sam reći da se više radi o arhitekturi nego o jeziku, a kod nas se same arhitekture vrlo slabo izučavaju na fakultetima, pa diplomci izlaze sa lošim ili nikakvim znanjem o tome. Takođe, uči se na prostim primerima, koji mogu da se urade maksimalno neefikasno, i razlika u odnosu na najbolje rešenje se neće ni primetiti (npr. na bazama daju studentima primer "naći radnika sa najvećom platom", a data tabela sa 10 radnika).


Malo smo napravili zbrku, neki od nas pričaju o konkretnom problemu (jedna žena unosi JMBG i ostale podatke u nekoj firmi, i SAMO ona ima pristup...), dok za neke daleko ozbiljnije primene (e-banking, e-commerce) mora o mnogo čemu da se razmišlja.
Kad je već pomenuta arhitektura, interesantna mi je prezentacija čoveka iz Google-a o razvoju njihove arhitekture: https://youtu.be/modXC5IWTJI


Tema je baš živnula, nadam se da se neki neće posvađati, jer se iz sučeljavanja različitih mišljenja i iskustava iz prakse mnogo toga nauči.
Od banalne stvari, tipa validacije nekog broja, dođosmo dotle da zbog toga možete da izgubite 90% posetilaca sajta :)
[ Predrag Supurovic @ 23.02.2017. 16:29 ] @
Citat:
VladaSu:
Na internetu ima hiljade i hiljade PHP CMS-ova tipa wordpress, opencart, mangento ... dajte mi link do barem jednog CMS-a koji je tako napisan.. source kod mozemo da vidimo.
Fora je sto necete naci ni jedan CMS, ni jedan kod (sme primera kako bi to moglo da se uradi) i necete naci ni jedan ozbiljan sajt da tako radi.


Sta podrazuevaš pod "da tako radi". Nekoliko puta toponavljas ali nisi konkretno rekao na sta konrketno milsis.

Ovo o cemu ja pricam se sasvim normalno tako radi u praksi. Moj frejmwork radi na tom principu. Druge CMS i frejmvorke nisam analizirao usitna crevca ali mi se cini da dobar broj ozbiljnih radi u slojevima, pocev od MVC paterna pa nadalje. Neko je to razradio više, neko manje ali sam princip je tu.
[ Predrag Supurovic @ 23.02.2017. 16:32 ] @
Citat:
svepomalo:
A kako bi uopste izgledala validacija JMBG-a u bazi?
Znam kako bih je napisao u php-u ali mi nije jasno u bazi, function, trigger, stored procedure?
Jel se ovde validacija na strani baze podrazumeva da raw input upucuas bazu pa da validiras ili nesto drugo?
Ako moze neki primer ili ja nesto nisam skontao kako treba iz cele ove prepiske.


Mislim da ce ti ovo pojasniti stvar http://cvuorinen.net/2013/05/v...g-data-with-triggers-in-mysql/
[ Predrag Supurovic @ 23.02.2017. 16:42 ] @
Citat:
mjanjic:
Htedoh reći da se na backend strani uradi sve što je neophodno od validacije, a potom se sve što je moguće od toga uradi i na strani klijenta ("prebaci" u smislu da se ne kontaktira server pri popunjavanju, osim ako se koristi AJAX), mada, moguće je korišćenjem ajax-a uraditi i backend validaciju svakog elementa posebno u toku popunjavanja forme, mada je za konkretan problem 'overkill', ali se za neke druge slučajeve može primeniti (npr. kod registracije na forumu provera da li je username slobodan).


Ne mora tu da bude "overkill"-a. Problem sa validacija ma nastaje samo ako se masovno upisuju podaci u tabele, a to je ipak relativno redak slučaj. Obično se upisuju podaci slog po slog. I to nije problem čak i pozvati validaciju sa servera.

S druge strane,neek validacije i ne može da radi niko drugi do server. Na primer, korsinik poručuje artikle i kada izabere neki artikal treba da se proveri da li tog artikla ima dovoljno na stanju. Taj podatak piše u bazi i mora se iz baze izvući da bi se uradiala validacija. Koliko će da traej validacija nije previše bitno jer korsinik ionako ručno ukucava podatke i vreme tu nije kritično (osim ako valdiacija nije baš toliko spora da pravi problem i za takav unos).

Bez poziva serveru mogu se raditi samo validacije koje se vrše nad podacima koji su klijentu već dostupni a to je, često, vrlo oskudno. Problem su validacije koje se zasnivaju na poslovnim pravilima. Za njih moraš da se obratiš poslovnom sloju aplikacije. I njih u stvariiam više i one su ustvari kritičnije jer se bave vrlo bitnim proverama, mnogo bitnijim od toga da li je neko polje popunjeno ili da li je ukucano slovo u polje gde sme samo broj.


Kada se radi neki masovni upit, onda se ionako ne radi validacija na nivou polja nego na nivou celog sloga (koja će naravno da validira i svako polje).

[ VladaSu @ 23.02.2017. 18:30 ] @
@Predrag Supurovic
Ne radim bankarske aplikacije u PHP. Da, to bi bilo cudno za PHP a pri tome mislim da cak PHP ne sme da se koristi za bankarske programe.


"Da tako radi"

Primer koji zelim da mi neko pokaze je primer da ti bukvalno mozes bilo koji iinsert, update da posaljes podatke iz forme tj requesta a da ih prethodno ne proveravas u PHP vec taj posao prosledis MySQL.
I pri tome da su ti podaci uvek ispravni.
Recimo uradis ovakav SQL iz konzole INSERT INTO phone_numbers SET num = '064/111-222-333' i da ti MySQL vrati poruku da samo VIP mreza podrzava devetocifrene brojeve a Telekom i Mobtel sedmocifrene.
Znaci da u MySQL proveris koja je mreza u pitanju i koji je format brojeva te mreze, opseg itd....
Ili recimo neko u polje mobilnih telefona ukuca 032 i ti mu kazes da ne postoji takva mreza kod nas. I to sve iz MySQL-a.
Znaci ne govorim o validacijama tipa da li postoji kljuc i nekoj drugoj tabeli i da stavim restrikciju na brisanje vec o mnogo detaljnijoj validaciji jer je receno da se validacija JMBG-a treba raditi u bazi.

Evo ovo sam upravo nasao na netu i mogu reci da mi sve ovo postujemo. Ovakve stvarni ne radimo jer je neko napisao ovaj tekst vec smo probali i merili performanse.
https://code.tutsplus.com/tuto...mysql-best-practices--net-7855

Ukratko: manje tabele su brze (a ako ima manje kolona ona je i menja) i tabele sa fiksnom sirinom su brze pa se sve kolone sa dinamickom duzinom smestaju u posebne tabele.




[Ovu poruku je menjao VladaSu dana 23.02.2017. u 19:51 GMT+1]
[ Predrag Supurovic @ 23.02.2017. 20:17 ] @
Vidjao sam takva rešenja sa procedurama na serveru baze. Ne baš na MySQL ali ne mari. I radilo je to. I čak je i imalo smisla a i nije ni bilo pogrešno. Neke baze imaju prilično razvijene skript jezike namenjene takvim stvarima.

Meni se taj pristup ne sviđa najviše jer ga smatram nepraktičnim - progam se piše se radi na dve platforme.

Dansa sam okačio link korisniku svepomalo koji baš daje primer kako se to radi.

Što se tiče podele tabele na dve, sve je to ok ako se podela radi pametno. Ako ta podela kao rezultat ima da svaki upit mora da JOIN-uje te tabele to je kontraproduktivno.

[ mjanjic @ 23.02.2017. 21:31 ] @
SQL tabela sa nekoliko hiljada kolona - svakako ne više od 4 096 :)

Pa je l' ta tabela normalizovana ili su zadužili za to nekoga ko je do juče radio u Excel-u (na početnom nivou na kome ne zna da ne moraju svi podaci biti na jednom Sheet-u ili čak u jednom dokumentu)?
Čak i da se radi o nekim podacima koji zahtevaju toliko kolona, zar se ne mogu neke kolone grupisati po kategorijama i smestiti u posebnu tabelu?

Ako i ne mogu, plus ako se pri čitanju zahtevaju podaci iz svih kolona (pa zato možda nema smisla deliti na više tabela), zar nije bolje koristiti neko noSQL rešenje?
[ nkrgovic @ 24.02.2017. 09:12 ] @
Pazi, ja sam radio optimizacije sistema koji procesira finansijske transakcije. Konkretno spomenuti limundo preko API-ja vuce podatke sa e-banking-a i iz poste, tako da kad uplatite limundo dopunu to vam odma legne na racun - a ne cekate da to neko rucno knjizi. Takav je poslovni model, uplate su relativno male a ima ih relativno dosta. Neke od njih cak idu i bulk. Sistem je php/mysql, pokupi, obradi i onda to prosledi dalje u finansijski sistem - znaci cist PHP koji radi full finansije.

Nikada niko nije probao da kaze "ajde ovo malo da ubrzamo skidanjem provera". Pri tom, biznis model je takav da se usporenje ne tolerise, u smislu da neke strane MORAJU da izadju za manje od jedne sekunde, bez kesiranja - jer to je real-time aukcija. Ja sam vrlo konkretno radio optimizacije DB sistema, tacno znam sta sam radio, zasto i kako. Par puta smo pricali da ima puno provera, odgovor je uvek bio isti : "Ako sistem uspori zbog kolicine uplata, dobicete koliko god vam treba za bolji sistem".

Takodje, vidjao sam vise sistema koji rade finansijske obrade, pisane u PHP-u, i skoro uvek je bilo isto.

Iskreno sumnjam da je iko ikad dobio odgovor da je prevelika kolicina novca koja ulazi u sistem problem i da nece dobiti sta mu treba da to resi. :)
[ Mister Big Time @ 03.03.2017. 21:45 ] @
Citat:
VladaSu:
@Predrag Supurovic
Ne radim bankarske aplikacije u PHP. Da, to bi bilo cudno za PHP a pri tome mislim da cak PHP ne sme da se koristi za bankarske programe.


Ko te to slagao, i to onako na tabloidnom nivou? Cuj ne sme, pa mozes u cemu god hoces, kakve to veze ima, banka ti daje API a ti mozes i preko kore od banane da ga konzumiras ako volis.

[ mjanjic @ 07.03.2017. 14:10 ] @
Pretpostavljam da to potiče od činjenice da (bar u Srbiji, a izgleda dobrim delom i u svetu) firme koje rade softver za finansijske transakcije i slično ne koriste PHP. Da li je to zato što se zahteva neki framework ili cela platforma čiji bi proizvođač davao neku vrstu GARANCIJE u vezi kvaliteta, tehničke podrške, rokova za ispravljanje bezbedonosnih propusta i slično, ne znam, ali kao što većina zna, zapatilo se nekoliko rešenja koja su dominantna, a PHP se tu nije nametnuo kao rešenje za neke velike projekte (prevashodno banke i drugi veći finansijski sistemi).

Drugi razlog, pre deceniju i više razvijeni su desktop klijenti za šaltere u bankama, i sada im ne pada na pamet da te klijente pišu ispočetka u PHP-u čak i ako bi im možda više odgovaralo da se svim servisima pristupa preko browser-a. Ako im treba neka nova opcija u interfejsu ili funkcija, samo dodaju u postojećem kodu i ažuriraju klijente...

Čak i da se pojavi potpuno nova banka koja traži potpuno novi sistem, firma koja ugovori posao će iskoristiti dobar deo koda rađen za neku drugu banku, neće sigurno sve pisati bukvalno od nule, osim ako je klijent spreman to da plati - a i tada će koristiti platformu za koju već ima iskusne programere.


Inače, da je bankama najbitnije da koriste što novije tehnologije i da po tome budu "in", već bi i oni odavno koristili node.js ili nešto slično što je novijeg datuma.
[ VladaSu @ 09.03.2017. 10:32 ] @
@Mister Big Time
Kazes da ti banka da API. Pa ti onda ne radis bukvalno bankarsku aplikaciju vec aplikaciju koja radi sa bankarskim API-ijem. Ti prakticno radis interfejs a ne bankarsku aplikaciju. Taj API ne sme biti u PHP.
Mislim da PHP i MySQL nemaju potrebne sertifikate da bi mogli da rade takav posao. (barame je bilo tako pre 5 godina, sada ne znam i zato sam rekao da pretpostavljam)
[ mjanjic @ 10.03.2017. 10:24 ] @
Kad smo već otišli na ovu stranu, meni je ta priča o tim "ispunjenostima uslova" za neku primenu interesantna, a retko se pominje van neke uskre branše (npr. firmi koje namenski rade softver samo za finansijski sektor).
Bilo bi dobro da nam neko ko se ovim bavi prenese iskustva.



Na primer, tako sam pre 10-ak godina negde pročitao podelu softvera za računarske simulacije, gde je bilo 5 ili 6 kategorija, i uglavnom MatLab nije mogao da se nađe u prvih nekoliko kategorija, jer su tu bili programi koji koštaju preko 30k evra, a ispunjavaju valjda neke standarde koji se u tom tekstu nisu pominjali. Pa šta da pričamo kad ni Wolfram Mathematica baš negde u to vreme nije mogla da reši kubnu jednačinu sa konstantnim koeficijentima čak ni numerički, iako se zada početno rešenje i interval unutar koga se sigurno nalazi približno tačno rešenje - problem je verovatno što algoritam koji se koristi za numeričko rešavanje jednostavno za tu jednačinu nije konvergirao ka rešenju, već je "skakao" levo-desno oko tačnog rešenje sa nikakvom ili vrlo sporom konvergencijom, pa program jednostavno zablokira.

Pretpostavljam da u nekim realnim primenama i MatLab može tako da se zaglupi, pa ne pripada kategoriji kojoj pripadaju neki daleko skuplji programi, koji pored većih mogućnosti imaju ugrađene mehanizme za takve slučajeve (ako ništa, bar da obaveste korisnika da taj algoritam ne daje rešenje i da eventualno ponudi neki drugi).