Kako to definisem posebno relacije da bi generisao view-e?

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:
a pitanje koje je lajtmotiv je: Koje je vase misljenje o tome da li se isplati koristiti abstraction layere uopste?

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:

Meni se manji i laksi alati mnogo vise svidjaju, a za alatima kao sto je Hibernate jos nisam imao potrebe, jer jos nisam radio aplikaciju gde se krece sa druge strane (od objekata, a ne od baze).

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

Ja sam ranije radio dosta u Delphiju (a cini mi se da se i Pedje secam sa yu.prog.delphi newsa? ) i apsolutno podrzavam taj vid automatizacije koji recimo Delphi pruza. Dovuces par komponenti, popunis par propertija i imas npr potpuno funkcionalni data-grid. Dajte mi to za php i bicu srecan kao kuce, pa makar morao da pozivam objekte da uradim SELECT *... :)

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

Nije to problem. Svaki bolji generator daje, je li, sors kod. A ti ga posle izmeni kako hoces. Jos bolje, izmeni sablon, tako da u jednom cugu dobijes rezultate vise upita.
Npr. Java to podrzava bez problema. Vise upita, jedna komunikacija sa bazom, dobijes kolekciju ResultSet-a nazad. Nema problema.

Pazi, ovo sto mi koristimo ne daje kod koji moze da radi sa 20 baza "istovremeno", nego kod koji radi sa jednom bazom. Ali ti mozes lako da kazes hocu sad kod za tu drugu bazu pa za 30 sekundi, eto ti koda (optimizovanog) za drugu bazu. Stvar je da kod svoje aplikacije ne moras da menjas.

Ajd sad kad vec pricamo..

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.

Eh Delphi... moram priznati da je su Turbo Pascal i Delphi nesto ponajbolje sto se dogodilo u mojoj programerskoj karijeri i principe na koje sam navikao u njima primenjujem gde god stignem.

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?

DBDesigner4 čuva šemu u XML obliku tako da se taj dokument uz pomoć jednostavnog stila može transformisati u Propel XML fajl. Više o tome...

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