3 typy dotazu (where, offset, limit) v DIBI

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Felix
Nette Core | 1189
+
0
-

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
+
0
-

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)

Jan Tvrdík
Nette guru | 2595
+
0
-

Také jsem vždycky používal klasický zápis (akorát lépe formátovaný).

Tharos
Člen | 1030
+
0
-

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 | 210
+
0
-

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
+
0
-

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
+
0
-

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 | 1189
+
0
-

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)

h4kuna
Backer | 740
+
0
-

taky používám třetí zápis, příjde mi průhledný a jednoznačný oproti ostatní a taky mám nad ním udělaný malý vraper

Tharos
Člen | 1030
+
0
-

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
+
0
-

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 | 8136
+
0
-

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