pomoc php unos samo brojeva u polje

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????

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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.

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?

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

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.

Potpis

about:networking

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.



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.



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.



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).



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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

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 :)

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Mislim da ce ti ovo pojasniti stvar http://cvuorinen.net/2013/05/v...g-data-with-triggers-in-mysql/

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

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).

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

@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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

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?

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

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. :)

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

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.

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.

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

@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)

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}