|
Citat:
|
Ne znam da li sam ja umoran ili ti? Naravno da nisam očekivao da mi pogađa misli, upravo sam ti pričao o vremenu potrošenom za definisanje svih parametara, views, kako god, i kažem da za mnogo kraće vreme, možeš da napišeš ovaj query (naravno, pod uslovom da znaš sql :) siguran sam da mnogi idu na te "layere" i "generatore" baš iz razloga što ne znaju SQL)
|
Citat:
Nisam ali sam radio sa kladionicama, znaš ono 1-1, 1-x, 1-2, ... pa golovi prvo poluvreme, pa golovi kraj, pa tačan rezultat... pa prvi daje gol, pa korneri, pa ... Ali ovo tvoje zvuči kao idealan slučaj za lepo normalizaciju, ali nećemo o tome sada. |
Odustajem, jer mislim da ne razumes viewe uopste:
Citat:
Ajd sad da pitam: jesi li pravio view u nekoj bazi? Nisi. Da jesi, znao bi da je to sto si otkucao, taj query, isto ono sto bi otkucao u nekoj bazi i sacuvao tamo kao npr. "view1". I onda mozes recimo SELECT * FROM VIEW1 WHERE.. Inace, kod mene je 22:15, bice da si ti umoran :) |
Citat:
Ebi ga, al malo zajebavas :) |
Citat:
Mada ovaj tvoj priemr je vise zgodan zbog validacije forme, nego sto je nesto velika usteda oko inserta...a koliko je meni u znanju ni jedan DB abstraction za php4 ne nudi nista na ovu foru... a sto se tice toga kako ja to radim, ja uglavnom koristim php i mada ima u php-u brdo gotovih klasa za validaciju, ja to obicno radim od slucaja do slucaja, jer mi retko treba vise od 10-tak polja po formi, a za to copy&paste radi posao... a sem toga ionako neka malo slozenija pravila kao validaciju email-a, CC-a ili zip kodova moras da pises rucno... a sam insert sam vec jednom pisao, otprilike ovako: PHP kôd:
i da se razumemo nemam ja nista protiv fancy DB abstraction layera, bas naprotiv ja bih rado da uzmem da koristim neki dobar (jer ovo sto ja koristim datira jos iz php3 i sigurno moze bolje da se odradi), ali mi smeta kod vecine sto su preglomazni, a pritom pola opcija koje nude mi ne trebaju. Ja bih neki jednostavan, brz, a funkcionalan... koristiti ove postojece na obicnim sajtovima je kao voziti porshea po beogradu, neces moci da primetis neku realnu prednost, osim sto je fancy i trosi vise.. Cisto kao mali primer moje logike, na sajtu AdoDB Lite mozete da vidite benchmarke koji pokazuju da je AdoDB oko 5 puta sporiji od cistog mysql-a (bez akceleratora, ali to je uobicajen slucaj)... a plus zauzme nekih 700KB memorije samo kad se includuje...to nije bas zanemarljiva stvar, priznacete? |
Citat:
U Propelu (PHP4 i PHP5 generator) imaš mogućnost setovanja validatora (sprečavaju insertovanje / update objekta sa neispravnim svojstvima), ali ne i podršku za automatsko generisanje / procesiranje formi. To moraš sam da implementiraš ili možeš da "pokradeš" neko gotovo rešenje kao što je Symphony na primer. Citat:
Čak iako sam nezadovoljan kvalitetom mnogih PHP5 rešenja ipak branim stav da je pametnije koristiti ovakve biblioteke nego se igrati sa čistim SQLom kod svih složenijih projekata. Za sitne stvari quick and dirty, za ozbilnije zna se... --- Pošto je bluesman izjavio da većina koristi ovakve biblioteke kako ne bi morali da koriste SQL iz razloga što ga ne znaju (ovu izjavu u najmanju ruku smatram netačnom) evo malo istorije. Prvi Windows programeri su morali da znaju Win32 API u dušu da bi radili. Pišu ljudi koji su radili u to vreme da je to jedan izuzetno komplikovan i smoran posao. Nisam probao tako da moram da im verujem na reč. Kako je vreme prolazilo, tako su alati sazrevali da bi danas koristio proste drag and drop metode za kreiranje formi, gotove biblioteke za rad sa prozorima i kontrolama itd itd itd. Sam API retko ko koristi, sve se radi kroz wrappere. Možda grešim u nekim detaljima, nisam se bavio programiranjem u to vreme tako da mogu da pričam iz prve ruke. Samo želim da istaknem da se programiranje razvija u tom smeru da skraćuje vreme koje programer treba da uloži u prljav, vodoinstalaterski posao (jer SQL to uglavnom jeste) i omogući mu da se više koncentriše na konkretan problem koji treba da reši, stvari unikatne za projekat. Slična stvar se desila i sa SQLom na ozbiljnim platformama (.NET, Java, Delphi...), a polako niču projekti koji portuju rešenja sa tih platformi (Propel je u suštini PHP verzija Torque projekta) ili osmišljavaju i implementiraju nova na "neozbiljnim" platformama. --- Ne znam da li da pokazujem jedan jednostavan Rails primer pošto mislim da je kod njega iskorišćen jedan od lepših pristupa? ActiveRecord je stvarno lepo napravljen. |
Off Topic: Retko dobra diskusija. thumbs up! :) |
Citat:
Vidi, one jednostavne query-je ja obično nazivam "hleb i mleko". Zato sam i pravio klasu koja će da mi taj proces automatizuje. Sve što je iole komplikovanije (obično i gotovo isključivo su to SELECT) mora da se piše ručno. Ono što pokušavam da kažem da ne postoji način da se proces automatizuje, najbolje što možeš je poluautomatski, znači jednostavno - automatski, komplikovano - ručno. Samim tim pada u vodu cela priča o automatizmu čitavog procesa. A izvlačiti čitav arsena teške artiljerije zbog "hleba i mleka" po meni nije optimalno rešenje. |
bluesmane, mislim da bi morao svoje tvrdnje da potkrepis time sto ces tu tvoju biblioteku da stavis u attachment :D
|
Citat:
|
Do GPL 3. A onda cemo morati sami da pisemo kod.
|
degojs: Ti si nekako uspeo da se ubaciš na pola priče, nisam siguran da znaš i history, stvar je u tome da su neki tvrdili kako ima je lakše da postupe otprilike ovako:
Naprave XML (ili neku alternativu) sa strukturom baze Provuku taj XML kroz neku klasu koja im izgeneriše druge klase Onda imaju sistem koji im omogućuje da ne pišu te osnovne querije Zatim, za bilo šta ozbiljnije, imaju poseban sistem u kojem opet moraju da navedu tačne relacije u bazi, ključeve, posebne "view"-ove (ne ono na šta ti misliš), pa onda to tako opet provlače kroz neke scriptove koji ime opet generišu neke kodove koji im omogućavaju da se "ne zezaju sa mysql". Po meni, svako radi kako mu odgovara, priča je o tome da to olakšava život. Ja tvrdim da je utrošeno vreme i energiju moglo efikasnije da se iskoristi, cela priča je samo o tome. Znači ne pričamo o mogućnostima mysql, evo, prvi post je krenuo ovako: Citat:
uz direktno pitanje: "Kakva su vasa iskustva?" Ne bih sada da ponavljam, ionako sam već nekoliko puta u ovoj temi, svoja iskustva po tom pitanju, kao i svoje stavove, samo podsećam na glavni tok. |
Pa ja sam iz tog razloga i napisao u svojoj, cini mi se drugoj, poruci o cemu ne pricam (ORM i sta-ti-ja-znam-sta).
Dalje, ovo sto mi koristimo (MyGeneration (koji podrzava cini mi se i PHP) i jos jedan alatcic "in-house-made") omogucuje mnogo vise (i sutra ako bi trebali da promenimo bazu, a necemo, ne bi imali nikakvih problema - svoj kod ne bi morali da menjamo, znaci imamo apstrakciju!), ali niti nas je briga za to, niti nam pada na pamet..(jeste, nesto se suska da bi mogli da menjamo jednu bazu, ali o tom kad bude..) E sad, sto ovaj tu jedan voli da mnogo prica o stvarima o kojima je verovatno samo citao.. kao da mi nismo culi za ORM, kao da i mi ne bi mogli da trubimo do zore.. Ali ja sam, kako rekoh, lepo napisao da o tome ne pricam. A evo sta kazu na sql2Java stranici, komentarisu verovatno najpoznatiji i najpopularniji ORM alat na Javi - Hibernate: Citat:
|
Off Topic: degojs, dolaziš iz potpuno drugog "sveta". Začudio bi se koliko PHP programera ne zna šta su ovakve biblioteke, da postoje, kako rade, da su odlično testirane i stabilne, koliko vremena štede itd itd. Samo uzmi činjenicu da većina još nije prešla ni na PHP5 gde se tek može pričati o pravom OOP. Svest većine PHP programera o patternima, naprednim OO konceptima itd je uglavnom jako ograničena... Ono što je u Javi potpuno normalno u PHPu je uglavnom novotarija i "preseravanje". No, to je sad već potpuno drugačija priča. Proces o kome blues priča je nasleđen od Java ekipe pošto je prvi Propel bio čist port (čovek nije želeo da izmišlja toplu vodu). Odluku da se koristi XML kao jezik za opisivanje u neku ruku i odobravam, ali potreba da se korist build alat (PHP port Anta) je skroz debilna po meni. Možda je u Javi normalno koristi build alate, ali u PHPu definitivno nije... To na stranu, način na koji ga je blues opisao zvuči kao da je to pola sata posla, što je daleko od istine. Sam proces se može podešavati tako da se izmene rade brže nego što neko može da otkuca jedan malo složeniji upit... |
Citat:
Ali Delphi ti takodje nudi mogucnost i da stvari radis na vrlo niskom nivou, ako treba i asembler da koristis... autori ovih DB klasa koje sam ja imao prilike da vidim ne omogucavaju low-level alternativu i to je po meni problem.. Nije samo da je ponekad naprosto brze i lakse otkucati par sql komandi... ponekad (cak prilicno cesto) je prakticno neophodno iskoristiti neku specificnu foru baze koja zahteva kontrolu koju pruza SQL... Uzmi recimo "SELECT SQL_CALC_FOUND_ROWS ..." i "SELECT FOUND_ROWS()". Jako korisna stvar da izbegnes dupli upit na bazi kad koristis limit da prikazes samo deo rezultata (paged results), sto ce reci prakticno na svakoj strani gde se nesto lista iz baze. Sa pre-generisanim klasama si osudjen na 2 upita, jedan count(*) i jedan sa limitom... Ili mozda i kriticnije, cinjenica da kod mysql-a ponekad zavisi koji ce index da se upotrebi (i da li ce se uopste upotrebiti) od redosleda uslova u WHERE klauzuli (to je po meni zapravo bug u query optimizeru, ali sta da se radi..). Kako ces to da kontrolises, ako ti klasa to pravi automatski i jos ti prepakuje tvoj SQL da bude kompatibilan sa 20 drugih baza? to je jedna vrsta problema, mozda ne toliko bitna za generalnu publiku, jedan upit ili 5 tesko da je bitno, recimo prosecna strana bloga u Wordpressu uradi 30+ upita i opet ga svi srecno koriste (ukljucujuci i mene jer sam lenj..) drugi ocigledniji problem (koji i mene muci priznajem) je naravno da je potrebno promeniti nacin razmisljanja o bazi za 90 stepeni, sto bas i nije jednostavno ako radis na odredjeni nacin godinama... za mene je SQL najprirodniji nacin obracanja bazi, jer sam tako naucio.. Da sam prethodno radio sa OO pristupom bazi (sto cenim da je po godinama slucaj sa Ilijom) verovatno bi mi se to cinilo kao super stvar u odnosu na kuckanje SQL-a... navika je mnogo gadna stvar... ja za sada jos uvek skidam i isprobavam razna resenja, cekam nesto sto ce da napravi kompromis izmedju lakoce rada i mogucnosti...we'll see...;) |
Nisam koristio DB abstractiol layer. SQL? Pa to je jednostavno! Ne znam, ne volim da komplikujem kad moze jednostavno. BTW i performanse su mi bitne, sto se debagovanja SQL tice, samo udrim $querydump=$querydump." ". $query; pri svakom upitu i na kraju echo $querydump i imam i vise debagovanja nego sto mi treba ;) Ne znam zasto da se mucim sa ko zna koliko komplikovanom bibliotekom za vrlo jednostavne stvari. Mozda, da moram da migriram na drugu bazu, ali je to sigurno vrlo pipavo, i opet bih zeleo da to redim rucno. Nemam onda tudji (citaj: bagovit) kod izmedju. Gresim li ja nesto ili je pravjenje XML za DB abstraction lejer isto sto i rucno dizajniranje baze? BTW mislim da je bolje da covek dizajnira bazu nego da imas 80 tabela u potpuno normalizovanom stanju ili sta vec glupi kompjuter moze da napravi. Kompjuter ne poseduje inteligenciju da me zameni u poslu, pa dali sam pravim CREATE upit za tabelu ili to pisem u XML, isto bi trebalo da bude.
PS: Kad moj kod zabrlja, bar znam sta je i gde je. Sa tudjim kodom nije tako, jer nemam dokumentaciju za kod. |
Poceli smo i da se ispovedamo, a :)
Citat:
Npr. Java to podrzava bez problema. Vise upita, jedna komunikacija sa bazom, dobijes kolekciju ResultSet-a nazad. Nema problema. Citat:
Citat:
Nije tu samo to problem. Kod takvog pristupa dosta vremena ode na pocetku na dizajniranje klasa i odnosa medju njima, interfejsi, nasledjivanje.. a to znaci da vidljivih rezultata nema tako brzo. A samim tim ako sve to moras da radis skoro je sigurno da je veliki projekat u pitanju. Pitanje je da li tvoj projekat uopste spada u tu kategoriju. Sa druge strane, bazu je uglavnom lako uraditi (pogotovo ako ti bluesman ne radi normalizaciju nakon sto si ti normalizovao pa denormalizovao istu ;) ) i mozes da krenes sa front-endom (pogotovo ako imas dobar alat koji ce da ti ustedi sav vodoinstalaterski rad na relaciji front-end <-> baza). I rezultati, makar rada u toku, su brzo vidljivi, a to se cesto jos i trazi. Mozda ce da bude drugacije kad jos i baze budu podrazumevano nudile tipove podataka a la java.Object, net.Object, php.Object i slicno.. "Doh!" sto bi rekao dinke, ovaj, Homer Simpson. |
Citat:
Pogodio si me u zicu, jer je i moj ideal da u PHP imam alat koji omogucava da radim nesto sa tom dozom prakticnosti koju Delphi pruza a uveren sam da kada bi se napravile klase koje funkcionisu na principu Delphijevih objekata, to bi bila odlicna stvar. Zamisli samo tu liniju: TTable|TQuery -> TDataSource -> TDBGrid u PHP-u... pa eventi, koji bi u stvari mogli biti mnogo mocniji, jer su skriptovi, a ne prekompajliran kod, kao u Delphi-ju. Meni se inace cini sasvim ok da koristim neki vizuelni alat kao sto je DBDesigner4 u kome opisem model baze, a onda tako definisan model koristim da izgenerisem osnovni wraper kod koji mi mora olaksati rad sa tim modelom. Ako bih morao rucno da pisem XML koji opisuje model, pa da, to bi bio sustinski neprihvatljiv pristup. Nego... Ova nadasve korisna i interesantna diskusija polako prelazi u nadmudrivanje i teoretisanje pa gubi ostricu. Sta mislite da uzmemo neki zamisljeni poluslozeni model podataka i da malo prakticno i konkretno poradimo na razlicitim pristupima u apstrakciji? |
Citat:
Propel XML fajl se može generisati i na osnovu postojeće baze podataka. Potrebno je koristiti creole target... Samom fajlu su kasnije potrebne sitnije dorade, ali je i to bolje nego pisati ga od nule. Na žalost ne mogu da pristupim Propel sajtu tako da ne mogu da linkujem na tutorijal. PS: Ja se izvinjavam ako konkretizujem previše. Ovde su uglavnom PHP programeri tako da mislim da ove informacije i linkovi nisu na odmet. Ako ništa, a ono bar da se ljudi koje interesuju upoznaju sa stvarima koje ove biblioteke mogu jer često mogu više nego što se na prvi pogled čini ;) |
Off Topic: E bas je dobar ovaj DBDesigner4, nisam ga do sad nikad koristio.. a jel ima on neku caku da se polju u tabeli dodeli komentar (da ne jurim po helpu) |
U verziji koju korsitim jedno od polja koja mozes da popunis prilikom definisanja polja tabele je i komentar.
|
evo jedne zanimljive (bar meni) price na ovu temu na koju sam slucajno naleteo trazeci nesto peto na sitepointu (da ne ispadne da sam opsednut bazama :P ):
http://www.sitepoint.com/forums/prin...t=82885&pp=200 |
Ajoj, al je taj što je to pisao blesav..
Citat:
Dalje nisam ni čitao. |
Trebao si jos malo da citas :) Ono o cemu covek pise ima dosta rezona a mi bas pomenusmo ovde Delphi jer je to njegov rezon i pokazao se veoma mocan i praktican.
Evo cemu se radi, napravis osnovnu klasu koja obezbedjuje uopstene mehanizme za rad sa bazom od kojih su vecina smao definisani ali ne i implementirani. Onda pravis klasu koja radi sa odredjenom bazom tako sto nasledis osnovnu klasu, obezbedis funkcionalnost za definisane metode a mozes da je prosiris i svojim. Mozes da napravis i klasu za neku drugu bazu na isti nacin, tako sto nasledis osnovnu, das joj funcionalnost i prosiris je. Neko sasvim treci, moze da napravi klasu za neku sasvim trecu bazu tako sto ce narpaviti novukalsu nasledjujuci osnovnu. Osnovna prenost je sto su sve te klase medjusobno kompatibilne, a promena podrzane baze se moze svesti na to da umesto jedne, koristis drugu klasu. naranvo, i dalej ostaje ogranicenje custom SQL upita, koji se ni na koji nacin ne mogu tek tako biti automatski portovani na drugu bazu. |
Citat:
Covek prica o Pear: DB i AdoDB, najpopularnijim abstraction layerima za PHP, i u jednom i u drugom se pisu SQL queriji direktno... tako da ne prica on gluposti nego ti ne znas kako se to radi u php-u... Da si procitao ceo text video bi da se prica o ideji da je (po njemu) pogresno bazu asptrakovati tabelu po tabelu, ili query po query, nego treba apstrakcija da bude zasnovana na prirodi entiteta sa kojim radis, tipa imas recimo klasu User i sve sa njom radis, a ne zanima te da li userove podatke cuvas u jednoj ili 5 tabela, to je pitanje implementacije same klase i zavisi, izmedju ostalog i od tipa baze... to je u stvari ista fora kao da imas View u bazi koji ti joinuje sve podatke za Usera, pa sa njim radis...tebe ne zanima odakle ti podaci dolaze u View, samo te interesuje koje se polje kako zove.... |
Postoji velika razlika između apstrakcije pristupa bazi i apstrakcije pristupa podacima. Ljudi kada govore o apstrakcionim slojevima (PHP svet) obično misle na ovo prvo, a trebalo bi da misle na ovo drugo.
PHP kôd:
Prava apstrakcija bi bilo nešto slično ovome: PHP kôd:
OK, dodato. Šta dalje? PHP kôd:
PS: Ja stvarno ne razumem zašto ljudi toliko ističu prebacivanje sa jedne na durgu platformu kao osnovnu prednost apstrakcionih slojeva. Taj slučaj je toliko redak da je to nešto što bi trebalo da se nalazi negde pri dnu features liste. Skroz je OK imati tu mogućnost, ali definitivno je ne treba toliko isticati. Ono što je meni najvažnije kod njih je što te oslobađaju vodoinstalaterskog posla na relaciji aplikacija-baza i mogućnost da se u aplikaciji posvetim samom baratanju podacima. PPS: Sva tri primera su iz glave i služe samo da ilustruju kompletnu priču kroz kod. |
Verovatno zbog nepoznavanja terminologije, ja takav nacin rada nazivam "modularni pristup", bas iz razloga sto meni, recimo, sloj za interakciju sa bazom predstavlja poseban modul, koji se automatski ucitava ako ja iz nekog treceg modula pozovem modul User (jer sticajem okolnosti korisnike cuvam u mysql bazi), a koje module on koristi da bi obavio posao apsolutno me se ne tice - koristim njegove metode i tako za svaki pojedinacan modul.
Mislim da se mogucnost transparentne promene db engine-a forsira pre svega sto omogucava developerima koji koriste razlicite baze da koriste isti abstraction layer na potpuno isti nacin kao da koriste bilo koju od podrzanih baza, dakle iz razloga popularizacije istog. A to sto programer koji koristi pgsql verovatno nikad nece hteti da koristi recimo sqlite... Pa, bitno je da ima i tu mogucnost... |
Citat:
|
I never said it's a Good Thing(tm) :)
|
Citat:
Citat:
|
Citat:
Uzmi bilo koji veci sistem i jednostavno je uvek slucaj da imas vise baza sa kojima moras da radis, jer su pre npr. 10 godina stavili jednu bazu, pa su pre 5 kupili drugu, pa trecu.. I ne, nisu bili pametni da kupe uvek bazu istog proizvodjaca, iz mnogih razloga. Znas li kolika je usteda u vremenu kad ne moras da se bakces u svom kodu sa svakom od tih baza posebno? I plus, kod je konzistentan, sto je jako lepo za odrzavanje. A ako apsolutno nemas potrebu za tim, onda ne treba ni da gledas ove alate. Kao i uvek - ne guraj nesto gde ti ne treba, a kad ti zatreba - znaces sam vrlo dobro. |
Citat:
|
Veće i kompleksnije? :) To je tema sada za drugu raspravu :)
|
Off Topic: Da, ovu ako su web aplikacije u pitanju (na DTP uglavnom jesu). |
Citat:
Nego, zasto uporno branis stav korporacijskih okruzenja gde je kompleksnost svakodnevna stvar? Jasno je da postoje slucajevi kada ovakvi alati sijaju punim sjajem, ali sam nekako stekao utisak da se ovde uglavnom prica o nekim malo-do-srednje kompleksnim problemima i projektima. Nemoj shvatiti ovo kao napad ili uvredu, samo te pitam zasto stalno branis taj stav. |
Pa ne, naprotiv, lepo sam napisao:
Citat:
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 07:46. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.