3 typy dotazu (where, offset, limit) v DIBI
- Felix
- Nette Core | 1245
Vcera vecer jsem resil strankovani na svych strankach.. Pouzivam pro
komunikaci s MySQL DIBI.
Pokud to dobre chapu, tak jsou 3 typy zapisu dotazu, kdyz beru v potaz where,
limit a offset..
DibiDataSource
<?php
$clanky = dibi::dataSource('SELECT * FROM [clanky]');
$clanky->where('kategorie=%i',$kategorieId);
$clanky->applyLimit(10,0);
$this->template->clanky = $clanky;
?>
DibiFluent
<?php
$clanky = dibi::select('*')->from('clanky');
$clanky->where('kategorie=%i',$kategorieId);
$clanky->offset(0)->limit(10);
// proc nejde, $clanky->limit(10) ?? nebo limit(10)->offset(0) ??
$this->template->clanky = $clanky;
?>
DibiQuery
<?php
$clanky = dibi::query('SELECT * FROM [clanky] where kategorie = %i',$kategorieId,' %ofs %lmt', 0, 10);
$this->template->clanky = $clanky;
?>
Doufam, ze jsem to napsal spravne. Muzu se zeptat co vam prijde nejlepsi? Popripade proc? A kde co vyuzivate? :) Abych si udelal nejaky obrazek o tom .. Me konkretne se asi nejvice libi ten fluentni zapis..
Editoval Felix (9. 2. 2011 14:45)
- Tharos
- Člen | 1030
Klasický zápis (tj. ten třetí) je oproti fluentu (tj. oproti tomu druhému) lépe optimalizovaný pro výkon. DibiDataSource se snaží elegantně řešit zejména problém se stránkováním, které do modelu z MVC/MVP striktně akademicky vzato nepatří (model nemá vůbec vědět o tom, že jím poskytnutá data někdo někde stránkuje). Nicméně v MySQL je bug, kdy se v poddotazech (kterých DibiDataSource využívá) nepoužívají indexy, což může být v reálu zabiják výkonu. Proto se teď myslím DibiDataSource v kombinaci s MySQL příliš nedoporučuje.
Editoval Tharos (9. 2. 2011 19:26)
- Tharos
- Člen | 1030
Já mám udělanou takovou triviální obálku nad klasickým zápisem, která klasický zápis ještě trošku zjednodušuje. V praxi v kódu písi například:
$news->find(5, array(
'fields' => 'title, perex, url',
'order' => 'published',
));
což je ekvivalent zápisu:
dibi::fetch('
SELECT [title], [perex], [url]
FROM [news] WHERE [id] = %i', $id, '
ORDER BY [published]
');
Docela mi takový styl práce s dibi vyhovuje.
Editoval Tharos (9. 2. 2011 17:22)
- Michalek
- Člen | 211
Používám fluent, jeho přehlednosti a výhodám se v mém osobním
měřítku nic nevyrovná. Jen místo limit a offset používám (když to
zrovna jde) ->fetchAll($offset, $limit)
. Ale někde jsem
zaznamenal možné zrušení téhle věci, tak bych na to nespoléhal.
Tharos napsal(a):
Klasický zápis (tj. ten třetí) je oproti fluentu (tj. oproti tomu druhému) lépe optimalizovaný pro výkon.
Můžeš to, prosím, upřesnit?
Editoval Michalek (9. 2. 2011 17:32)
- Tharos
- Člen | 1030
Michalek: Zde o tom píše David
Já právě fluent z tohoto důvodu nepoužívám. Klasický zápis s tou mou obálkou (která zpomaluje neměřitelně) je pro mě srovnatelně pohodlný a je-li fluent samotným autorem knihovny brán jako akademický…
Editoval Tharos (9. 2. 2011 17:36)
- srigi
- Nette Blogger | 558
Za velku vyhodu fluent povazujem moznost skladania dotazu pocas runtime:
$clanky = dibi::select('*')->from('clanky');
$clanky->where('kategorie=%i',$kategorieId);
if (NEJAKY_VYRAZ) {
$clanky->where('posted>%i',$nejakyParam);
}
Toto robit inak ako pomocou fluent je velmi neprakticke.
- Felix
- Nette Core | 1245
Takze DibiFluent je akademicky, tzn. spise jinaci typ zapisu, ktery se ovsem nedoporucuje. DibiDataSource ma zase problem s MySQL bugem? Z toho mi tak trochu plyne, ze nejlepsi a nejrychlejsi je klasicky DibiQuery?? Je to tak? Avsak mi to prijde trochu zvlastni, odhadoval bych ho az na treti pozici. Jelikoz mi prijde, takovy moc nemotorny.
Editoval Felix (9. 2. 2011 21:14)
- Tharos
- Člen | 1030
srigi:
dibi::fetchAll('
SELECT * FROM [clanky]
WHERE [kategorie] = %i', $kategorieId,
'%if', NEJAKY_VYRAZ, 'AND [posted] > %i', $nejakyParam
);
To přece není až tak nepraktické, nebo ne? :)
Felix: Ono asi dost záleží na tom, jaký máš vztah k samotnému SQL. Já osobně velmi vřelý, jsem jím „odkojen“ a u řady problémů mi tak nějak rovnou mimoděk naskakují v hlavě SQL dotazy… S použitím nějaké obálky (přece jenom občas je SQL dost psaní) mně osobně vyhovuje suverénně nejvíc.
Editoval Tharos (10. 2. 2011 8:57)
- bojovyletoun
- Člen | 667
Používám buď normální zápis (správně nazváno DibiResult) nebo Fluent, na co je nálada. DibiDatasource zřídka, jen když mě k tomu nutí něco (třeba GriditoModely).
- U fluentu je velká výhoda u skládání.
- Fluent preferuji při insert/update/delete. !Akorát nezapomenout na execute() (velká výhoda)
- (ne tak velká)výhoda Datasourcu je možnost řazení při selectu
- Klasický zápis je pro mě přehlednější (a rychlejší napsat)
Pár poznámek z praxe:
- spousta (psáno opatrně) lidí neví co jsou indexy, takže fluent moc nezpomalí :)
- Klasický zápis používají geekové a guru, protže je to nejblíž „raw SQL“ :)
- dřív lidi poměřovali údy. Teď je moderní doba a poměřujou se rychlosti frameworků a DB layerů.
- David Grudl
- Nette Core | 8227
Akademický je asi špatné slovo, nechť fluent používá každý dle libosti, jsou i věci, které se bez něj řeší docela špatně. U Jakuba jsem reagoval jen na použití ve výkonnostním testu. DataSource je bohužel v MySQL nepoužitelný.