|
Citat:
To što neka biblioteka ima podršku za veliki broj platformi znači par stvari: 1. Dizajnirana je tako da može da bude specijalizovana na taj način. Sam Factory pattern nije težak za napraviti i ne donosi nikakav značajan pad pad performansi. 2. Dobro i jasno definisan API. Bez toga ovi sistemi ne bi bili mogući ili bi bili jako loši. 3. Dosta ljudi je umešano u razvoj i testiranje tako da je stabilnost datog koda daleko veća nego što bi ti sam mogao da postigneš. 4. Portabilnosti 5. Smanjenje količine koda koju ti sam treba da napišeš, free Konkretno, svaki od abs layera možeš terati u minimal modu, tj. samo sa podrškom za platformu koja ti treba. Iako dolazi sa malim milionom zapakovanih fajlova, ADOdb zahteva nekih 5 fajlova u minimalnoj instalaciji da bi radio kako treba. U manualu piše šta je sve potrebno za šta i savet kako možeš okresati instalaciju. Mana je složeniji kod sa padom performansi, ali uz napomenu da ovo u velikom broju slučajeva ne predstavlja problem. Uostalom, zašto koristite PHP? Možete sesti, smisliti rupu u saksiji i svoju novu maestralnu web aplikaciju napisati u C-u ;) Off Topic: Znam da bar jedna osoba ovde želi da zna koliko tuđeg koda koristim u svom radu. Sorry, ja isto često volim da izmišljam rupu u saksiji tako da od tuđeg koda koristim samo Propel (on koristi Creole). Upoznat sam sa mnogim gotovim biblioteka jer volim da analiziram tuđa rešenja. Tako dolazim do dobrih i proverenih ideja, gledam gde su greške, šta se može uopštiti, a šta izbaciti itd. Možda mali dodatak, da ne dođe do zabune: stvari kao što su singleton, factory, strategy, activerecord, decorator, facade i tako dalje su imena patterna, ne imena gotovih biblioteka (osim ActiveRecorda gde se najpoznatija Ruby implementacija ovog patterna upravo tako zove). Neki korišćenje ovih termina mogu gledati kao preseravanje, ali je činjenica da se pomoću njih može predstaviti kompletan jedna koncept uz pomoć jedne do dve reči. |
Citat:
U čemu je fazon da ja sad treba da pišem za svaku od 50 tabela u bazi podataka - da za svaku treba da pišem INSERT, DELETE, SELECT i UPDATE izraze? Koliko je to cimanja, ako se zna da pola od tih tabela ima 30+ polja? Što je najgore to je dosadno do zla boga. Ma idi bre :) Jednom kad probaš neke alate iz te kategorije, povratka nazad nema. JOINs? Šta sa njima, tačno? Definiše se potrebni VIEW u bazi, a onda opet dobijemo klasu da pozovemo ovaj pogled. Što se kvaliteta tuđih alata tiče, zavisi šta se koristi. Neka rešenja su proverena do bola i pouzdano rade u svim situacijama. Performanse? Nisam siguran da ima problema, ima li ko kakav test? Nego Gorane, da vidimo konkretno. 1. Imaš tabelu sa 40 polja. 2. Imaš jednu stranicu na kojoj korisnik unosi podatke za polja te tabele 3. Imaš drugu stranicu gde trebaš da prihvatiš unete podatke i spremiš u bazu Kako ti to radiš? |
Citat:
Citat:
Prvi je onaj koji si ti prikazao u primeru: klasa koja obavlja sve one standardizovane procedure nad tabelema i podacima. Bilo bi idealno kada bi toj klasi mogao da "nacrtam" model baze a da mi ona obezbedi sve potrebne mehanizme pocev od kreiranja same baze pa do standardnih funkcija. Drugi nivo su klase koje nasledjuju osnovnu klasu u prosiruju je specificnostima potrebnim za konkretnu namenu. One bi po pravilu sadrzavale rucno pisan kod. Tako imas mogucnost da radis onako kako ti u trenutku odgovara, mozes da uopstavas, ako mislis da je potrebno, a i ne moras jer imas prostora da za specifican problem napises i specifican kod. Ono sto ces sigurno dobiti to je citkiji kod, koji je lako pratiti i odrzavati. Citat:
Citat:
|
Citat:
To što alati podržavaju 20 baza, ne znači da ćeš ti u svojoj aplikaciji obavezno da koristiš kod koji može da radi sa 20 baza podataka. Ti ćeš od tih 20 podržanih baza da odabereš jednu i dobiješ klase specifične za tu bazu (i tvoje tabele). 2) Uostalom kakvo smaranje sa pisanjem koda za 16 baza, sve i da imaš potrebu da radiš sa 16 baza? Ko to radi tako? Gde? Programira se "against interface", tako da te uopšte nije briga koje klase se koriste. Bitno je da sve te klase podržavaju isti interfejs tako da onda za tebe nema razlike da li u pozadini koristiš klasu koja radi specifično sa Oracle 9i ili MySQL 5. U pitanju je Factory design pattern. Možda i grešim ako si pričao samo za PHP - možda tamo moraš da se smaraš sa pisanjem različitog koda za svaku bazu. Ne znam za PHP, ali znam gde ne mora tako. |
opet se vracamo na istu pricu, upotreba vise baza....ako ces uvek koristiti istu bazu, onda ce i interfejs koji koristis da bude uvek isti sve da koristis i obicne drajvere za bazu direktno.
Znaci ajde za sekund da pretpostavimo da imam mysql i da nikad necu koristiti nista drugo. Ako zanemarimo apstrakciju baze koje su onda prednosti upotrebe abst. layera ? Degojs rece kako oni skracuju vreme kad imas dosta tabela, pa za svaku treba da se pišu INSERT, DELETE, SELECT i UPDATE i kako je to cimanje bez apstrakcije? E sad meni nije jasno (mislim zaista ne znam, pa pitam) kako i koliko ti automatski generisane klase pomazu u tom slucaju? Koliko moze jedna automatski generisana DB abstraction klasa da ti ustedi truda? Iz primera imam utisak da ti i dalje moras da znas koji objekat da instanciras (za svaku tabelu ima jedna klasa ako sam dobro shvatio?), a i onda da pozoves odredjenu metodu i kazes joj sta i sa kojim poljima da uradi. Meni se to cini kao drugaciji vid zapisivanja istih stvari koje bi radio iz SQL-a, i cini mi se da to moras da uradis za svaku tabelu, i za svaku akciju nad njom, bas kao i sa SQL-om, right? u cemu je onda usteda? Ajd pls. dajte neki primer, jer ne kapiram... A nije bas svejedno kolika je klasa koju koristis, jer na primer AdoDB ima footprint od 700KB sto nije bas malo, pogotovo ako ti skripta samo radi jedan select * from tabela |
Samo da ukratko razjasnim o cemu ja tacno pricam, posto je na temi bilo reci o vise stvari.
Sto se mene tice: ja nisam jos imao priliku da radim nesto gde se menja baza (imao sam i imam priliku da radim sa vise baza na jednom sistemu; nebitno za ono sto sam imao na umu). Ima nagovestaja da cu uskoro prvi put i to da radim, ali o tom kad se desi :) Dalje, ja ne pricam o alatima za mapiranje objekata u relacionu bazu. Nisam to nikad radio te i to preskacem. E ono sto JESAM radio jeste otprilike ovako: nove tabele u bazi - oko 50 tabela, pola od njih ima 30+ polja. Citat:
Pazi sad, da ja dobijem mogucnost da iz aplikacije radim UPDATE/INSERT/DELETE/SELECT svake od tabela (kao i komplikovaniji SELECT) meni je potrebno, jednom kad su tabele (i pogledi, ako treba) u bazi gotove, tacno nekih 30 sekundi dok program generise te klase. I gotova prica. Koliko je tebi vremena potrebno da za svaku tabelu imas istu funkcionalnost? Da je kod konzistentan, cist, pregledan i DOBRO testiran? Ej bre, znas li koliko tu ima fizikalisanja?? I onda jos gledaj da nisi neko polje preskocio..? Zato i pitam: kako bi ti to uradio, koliko vremena bi ti trebalo? Kad ovo odgovoris, idemo dalje, nije tu kraj price: zato sam i pitao Gorana kako bi on uradio onaj slucaj koji sam opisao. Sve sa malo koda, jer mi se cini da vi olako preskacete neke detalje koji, bar mene, smaraju do zla boga. |
Citat:
Sa bibliotekom koju trenutno koristim, a koja je vrlo slicna phpLib postupak je otprilike: $db->query('neki_sql'); gde je 'neki_sql' INSERT, UPDATE, ALTER TABLE ili koji god sql query mi treba... Ako radim SELECT onda bi jos trebalo da pokupim rezultate sa : while ( $db->fetch_next()) { ... } ili sa $a = $db->fetch_all(); Sama klasa brine o tome da se (na osnovu podatak iz config fajla ili direktno propertija nasledjene klase) poveze na bazu (ako vec nije povezana), da uhvati greske(poziva registrovanu callback funkciju), da oslobodi resurse kad nisu potrebni, a postoji i varijanta query metode u kojoj radi escape promenjivih: $sql = "SELECT * FROM nesto WHERE id=? AND ime='?' "; $db->query($sql, 1, 'pera'); ovo je moj dodatak koji naprosto uradi escape parametara i zameni ih umesto ? u sql upitu (nije pravi sql prepare, jer php drajveri ne podrzavaju to...) sa $db->num_rows ili $db->affected_rows moze da se proveri koliko je rezultata, odnosno promena izvrseno... I onda tako za svaku potrebnu operaciju nad svakom tabelom... koliko ce ovo biti citljivo zavisi naravno od komplikovanosti SQL upita (na webu obicno nisu preterano komplikovani), a i od toga koliko onaj ko cita zna SQL :) Ajd sad please daj da vidim kontra primer, kako ovo uraditi jednostavnije... ja i trazim nacin da ustedim vreme, zato sam i zapoceo celu pricu... |
Nemoj ti meni najjednostavniji primer sa SELECT * WHERE a=b AND c=d, nego daj lepo da vidim primer za INSERT i UPDATE u tabelu gde imamo 30 polja. Ja uporno ponavljam "veci broj tabela, tabele sa vise polja" a ti meni "Evo ti SELECT *" gde prakticno nije ni bitno koliko polja ima :)
Hajde lepo, tabela ima 30 polja. Da vidimo INSERT, da vidimo UPDATE. Pa onda to ponovi 25 puta, za 25 raznih tabela. Hajde da vidimo da li je smaranje ili nije. 1. na prvoj stranici ima recimo 30 polja u koje korisnik unosi neke tamo leve podatke Kôd:
<form .... >Kako kod tebe izgleda druga stranica koja ce da prihvati podatke i doda novi zapis u tabeli u bazi? Kod mene, evo kako bi to izgledalo u Javi, ovo je citava stranica: Kôd:
<jsp:useBean id="customerDataForm" scope="request" class="formBeans.CustomerDataFormBean" > boolean OK = customerDataForm.update(); Pazi bre, ja niti sam klase kreirao, niti sam pisao SQL. I tako moze za svaku tabelu. Samo sam napravio tabele u bazi. Ako moze i kod tebe ovo isto, a drugacije, pricaj :) Meni je ovo bre usteda i vremena i zivaca. |
Citat:
Ako tabela ima 40 polja, onda nešto nije u redu sa tom bazom, fali joj malo sređivanja :) Ili radiš sajt za neku kladionicu :) Pa čak i ako ima, koliko ima takvih tabela? 1 u 10 godina? No dobro... Ja sam napravio svoju klasu koja ne samo da radi te poslove tipa INSERT, UPDATE automatski nego generiše formulare, generiše server I client side error control (client: javascript, pre submit). Znači korisnik klikne na submit, ja u kodu imam nešto ovako: PHP kôd:
ili getDeleteQuery (); i onda izvrsim query koji je u stringu - posaljem ga DB klasi. Znači, ovo je odgovor na "kako ti to radiš", ali mislim da namerno skrećeš sa teme. Niko ovde (odnosno, bar ne ja) ne priča o ovakvim query-jima. Ja govorim recimo o situaciji: Kôd:
$sQuery = "SELECT c.*,Pored toga, vecina stvari se cesto ponavlja, tako da recimo ako jednom napravis klasu users gde se on loguje, menja podatke, pretrazuje usere... onda je posao oko novog sajta samo da prekopiras klasu koju imas i eventualno dodas ili oduzmes par polja koja su specificna za odredjeni sajt. I kažeš cimanje pisati sve te INSERT, UPDATE... Slažem se da je dosadno, ali veće je cimanje definisati tabele kao neki XML ili šta god, pa onda definisati relacije, pa views, pa ovo-ono (pri tom, uvek dođe do neke izmene kasnije pa moraš da predefinišeš relacije pa sve ponovo), pa onda to provaličit kroz neki kod koji će da generiše drugi kod koji bi trebao da radi sa nečim trećim... Koja je tu ušteda u vremenu ili trudu? A pokrenuo si ne samo artiljeriju nego i strateške bombardere i nuklearni arsenal da nebi pisao par querija koje si mogao da napišeš za kreće vreme nego što si napisao postove na ovoj temi. I non sto pričate o portabilnosti. Nice. Ali, WTF? Koliko puta si morao da portuješ nešto na drugu platformu? Once in a lifetime? Hajde da čujemo koliko ljudi je portovalo nešto na drugu platformu gde mu se isplatio portabilan kod? Možda par? Možda ni jedan. |
Citat:
Jesi radio nekad aplikaciju koja radi sa pacijentima, bolestima, nalazima, simptomima, tretmanima, epidemijama i slično? Forme na kojima radimo dobivamo direktno iz prakse. Otkud znam, možda bezveze popunjavaju formulare i slično. Eh sad.. možda smo i mi i oni ludi, a možda ti ne znaš tačno šta i kako to izgleda.. Čak smo i, naravno, forme gde je god bilo moguće "obrnuli" u tabelama tako da se dinamički generišu iz redova u tabeli, a ne kolona. Eh. Citat:
Onda i pričamo o istoj stvari. Ostaje da vidimo kako ivanhoe radi ovo isto :) |
| Vreme je GMT +2. Trenutno vreme je 12:30. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.