DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   PHP frameworks, again (http://www.devprotalk.com/showthread.php?t=7873)

jablan 22. 10. 2009. 21:24

Citat:

Originalno napisao bluesman (Napišite 74683)
Mister, pa ja ne pričam o ovome, ovo je smešan query i ovo je savršeno jasno da je to ono što nazivam "hleb i mleko". Ja pričam o daleko komplikovanijim stvarima. Kao što rekoh, FW je super da ti smanji posao oko ovakvih sitnica.

Ček, ti si se žalio da ti FW "generiše" neoptimizovane upite. Ja samo kažem da ništa FW "sam" ne generiše, već sam generišeš, samo korišćenjem FW-a kao jezika koji se manje više jednoznačno mapira na SQL. Nema tu magije, SQL je onoliko komplikovan koliko ga komplikovanim napišeš, bez obzira da li koristiš FW ili direktno SQL. Zato kažem da mislim da mistifikuješ celu priču oko FW-a, jer nisam siguran da znaš kako to tamo radi.

bluesman 22. 10. 2009. 22:36

Govorim o onim "munjama" tipa belongsTo... hasOne... hasMany, pa razne schema, pa ti kao kreiraš relacije a onda ti "on" sam generiše querije. I ti tvrdiš da ne "ništa ne generiše sam"? Ko generiše mysql, ti ili fw?

nixa 22. 10. 2009. 23:44

^ ti baš ne voliš ORM :)

ivanhoe 23. 10. 2009. 00:06

evo gledam nesto Kohanu, upit:
Kôd:

ORM::factory('user')->where('username', 'bla')->find();
generise sql:
Kôd:

SELECT * FROM users WHERE username='bla' ORDER BY users.username ASC LIMIT 1
nije li to debilno? Sam poziv ORM metode je duzi od SQL-a koji bi trebalo otkucati, a generisani upit je pun nepotrebnih stvari, koje u opstem slucaju mogu itekako da pogode performanse, a potpuno su nevidljive korisniku, on nece imati pojma da je upit takav dok se baza negde ne zakuca. I onda pogledas slow query log u bazi da vidis zasto se koci, i nadjes ovaj select, i kako onda u kodu pronadjes sta generise taj select? Nikako, moras da logujes upit po upit dok ne vidis odakle dolazi...

E sad, daleko od toga da sam ja protiv stvari koje povecavaju produktivnost, samo ja na to gledam iz drugog ugla nekoga ko cesto odrzava i prepravlja tudji kod, a ne samo da gleda kako da za sto manje vremena i truda napravi nesto sto koliko-toliko fercera.. ako je efikasnost rada jako bitna, a lose performanse se resavaju kupovinom jaceg hardwera, onda je ORM pristup super..

bluesman 23. 10. 2009. 00:11

^ baš to. A ja čak govorim o komplikovanijim situacijama.

bOkIcA 23. 10. 2009. 00:36

ORM ne volim, komplikacija mi je kao i Smarty, koristim CI Active Record klasu.

u modelu funkcija za count npr:
PHP kôd:

    function count($lang 'en'){
        
$this->db->where('language'$lang);
        
$this->db->from('table_name');
        return 
$this->db->count_all_results();
    } 


ili get
PHP kôd:

    function get_all($lang 'en'$start_row 0$data_per_page FALSE$order_by FALSE$order_type FALSE){

        
/* ... cuted part ... */

        
$this->db->from('table_name');
        
$this->db->join('table_name_2''table_name_2.id = table_name.id''left');
        
$this->db->where('language'$lang);
        
$this->db->order_by($order_by$order_type);
        
$this->db->limit($data_per_page$start_row);
        
        
// execute query
        
$query $this->db->get();

        
// return data
        
if ($query->num_rows() > 0)
            return 
$query->result_array();;

        return 
FALSE;
    } 

Beneficije su automatsko eskejpovanje i mogucnost rada sa drugom bazom.

a uvek moze i pisan sql sa eskejp:
PHP kôd:

$sql "SELECT * FROM some_table WHERE id = ? AND status = ? AND author = ?";
$this->db->query($sql, array(3'live''Rick')); 


bluesman 23. 10. 2009. 13:16

Citat:

Originalno napisao bOkIcA (Napišite 74698)
Beneficije su automatsko eskejpovanje i mogucnost rada sa drugom bazom.

Eh, koliko puta sam čuo (pročitao) ovo... nake mi nađe neko jedan jedini slučaj kada je neko krenuo da radi u jednoj bazi i završio na drugoj. Ili nešto mnogo verovatnije, koliko ljudi uopšte koristi nešto drugo od onoga što najčešće koristi (u zavisnosti od firme u kojoj radi). Nemojte da se se zezamo više sa ovakvim argumentima, to je čisto teoretski tipa "a šta ako udari kometa?" a u praksi zakucani ste sa jednom bazom i tu ćete verovatno ostati do kraja profesionalne karijere u firmi.

bOkIcA 23. 10. 2009. 13:32

Kada se radi razvoj aplikacije koja treba da ima mogucnost da radi na raznim bazama onda je ovo pristojno resenje. To da se prebacujes sa jedne baze na drugu u toku rada je nesto sto nisam rekao.
I ne znam sto si uopste umesao ORM u pricu o FW.

cvele 23. 10. 2009. 13:34

Citat:

Originalno napisao bluesman (Napišite 74721)
Eh, koliko puta sam čuo (pročitao) ovo... nake mi nađe neko jedan jedini slučaj kada je neko krenuo da radi u jednoj bazi i završio na drugoj. Ili nešto mnogo verovatnije, koliko ljudi uopšte koristi nešto drugo od onoga što najčešće koristi (u zavisnosti od firme u kojoj radi). Nemojte da se se zezamo više sa ovakvim argumentima, to je čisto teoretski tipa "a šta ako udari kometa?" a u praksi zakucani ste sa jednom bazom i tu ćete verovatno ostati do kraja profesionalne karijere u firmi.

U praksi tip je razvijao vBulletin na mysql i onda odlucio da pruzi podrsku za pgsql, oracle itd.
Da li je napravio 4 izdanja ili je koristio db apstrakciju ?

nixa 23. 10. 2009. 13:45

^ mislim da ovde nije baš reč o DB apstrakciji .. a i sumnjam da nisu optimizovani upiti za svaki db tip posebno


Vreme je GMT +2. Trenutno vreme je 04:41.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.