Dotaz: php pdo prepare a generovany select

[janci]

Nazdar bazar.

Ucim sa pdo a riesim problem ako urobit prepare pri zlozenom selecte. Teraz to mam zrobene tak

if($a) {
  $where='t1=\''.mysql_real_escape_string($_POST[a]).'\' and';
}
if($b) {
  $where='t2=\''.mysql_real_escape_string($_POST[b]).'\' and';
}
if($c) {
  $where='t3=\''.mysql_real_escape_string($_POST[c]).'\' and';
}

$query='SELECT * FROM table where ('.$where.' t4=\''.mysql_real_escape_string($_POST[d]).'\')';

jasne, ze tento priklad je ilustracny a v realnom kode generujem select tak o cca 300 riadkov z roznych premennych, pomocou roznych podmienok s roznymi joinami, subselectami a podobnymi hovadinami, proste salenota. Teraz to nie je problem, lebo je jasne co je sql parameter, co pouzivatelsky vstup a pod. Ale pri pdo som z toho jelen.

Dikes a zdar: janci

Odpovědi

[logik]

Normálně skládej select s "pojmenovanejma placeholdrama" a vedle toho pole s parametrama. Např.:

if($a) {
  $where='t1= :a';
  $args[':a'] = $_POST['a'];
}
...
$args[':d'] = $_POST['d'];
$query="SELECT * FROM table where $where AND t4= :d";
...
$sth = $dbh->prepare($query);
$sth->execute($args);

?>

Jinak v kodu nahoře nedáváš řetězce do uvozovek. Sice to projde jen s varováním, ale je to čuňačinka

[Kit]

Sice přesně netuším, co to má dělat, ale mohlo by to vypadat třeba nějak takhle:

<?php
$where = array();
if ($a) {
    $where[] = "t1=?";
}
if ($b) {
    $where[] = "t2=?";
}
if ($c) {
    $where[] = "t3=?";
}
$where[] = "t4=?";
$query='SELECT * FROM table where ' . implode(' and ', $where);

Pokud to však máš skutečně na 300 řádcích, asi není vše v pořádku a bylo by vhodné se nad tím zamyslet. Kdysi jsem něco takového vyrobil, ale tvé zadání je tak podivné, že na to nepasuje. Bylo to dokonce ještě o něco kratší.

[logik]

Rozhodně bych nepoužíval při spojování selectu nepojmenované parametry (placeholdery). Zadělává to na průšvih, že to pak pospojuje jinak a udělá z databáze guláš (teda je to select, takže tady to neni tak citlivý, ale princip je princip).

Ale jinak Ok.

[Kit]

Vypadalo to nějak takhle:

<?php
$filtr = array(
    'jmeno' => 'Adam',
    'boty' => '42',
    'datum' => '2014/10/03',
);
$query = 'SELECT * FROM table WHERE ' . implode(' AND ',
    array_map(function($field) {
        return $field . "=?";
    },
        array_keys($filtr)));
$select = $db->prepare($query);
$select->execute(array_values($filtr));

Samozřejmě není velký problém použít pojmenované placeholdery, ale to si snad už janci dodělá za domácí úkol.

[Tomáš]

Nebylo by jednodušší tu konstrukci supersložitého dotazu vyřešit uvnitř uložené procedury?

A v tom perlu nebo co to vlastně je, zavolat jen tu proceduru s příslušnou sadou parametrů

[Kit]

To asi nepůjde, protože počet parametrů zřejmě není konstantní.

[Tomáš]

Potom by jistě šlo parametry uložit do pomocné tabulky prostým insertem a uložená procedura by si to vyčetla.

[Kit]

To by určitě šlo, jen by to asi byl trochu overkill. To už bych raději ty atributy serializoval. Tím se obloukem opět vracím k SQL

[Josef Kufner]

To, co hledáš se jmenuje query builder. Existuje jich povícero, Google ti jich pár poradí, ale většinou jsou moc chytré. Například takové FluentPDO si generuje joiny, když se překlepneš v názvu tabulky. Takže jsem se nechal inspirovat u FluentPDO, Dibi a pár dalších a napsal Flupdo. Je dostatečně hloupý, snaží se neházet klacky pod nohy a měl by mít 100% pokrytou syntax MySQL.

Použití takového query buileru s fluent API vypadá nějak takto:

$q = $flupdo->select('*')->from('table');
if ($a) {
  $q->where('t1 = ?', $a);
}
if ($b) {
  $q->where('t2 = ?', $b);
}
$result = $q->execute();

[Kit]

Že bych si z toho udělal plugin do editoru jako off-line generátor SQL dotazů?

[Josef Kufner]

Proč off-line generátor? Tyhle věci jsou k tomu, aby SQL generovaly za běhu.

[Kit]

Slepování SQL dotazů dělám tak výjimečně, že se mi vyplatí použít miniaturní skript "na míru". Viz výše.

[Josef Kufner]

Já naopak došel k tomu, že používám téměř výhradně query builder, neboť je s ním snažší umisťovat parametry (otazník a dosazovaná proměnná jsou velmi blízko v kódu) a pokud se později dotaz rozroste (byť jen o prosté podmíněné přidávání podmínky), není potřeba ho pro query builder přepisovat.

[Kit]

Však v tom příspěvku to tak mám na dvanácti řádcích. Knihovnu kvůli tomu nepotřebuji. Pokud přidám podmínku, znamená to jen přidat jeden řádek v seznamu $filtr.

[Josef Kufner]

Tak malé srovnání:

Společný kousek:

$filtr = array(
    'jmeno' => 'Adam',
    'boty' => '42',
    'datum' => '2014/10/03',
);

To tvoje:

$query = 'SELECT * FROM table WHERE ' . implode(' AND ',
    array_map(function($field) {
        return $field . "=?";
    },
        array_keys($filtr)));
$select = $db->prepare($query);
$select->execute(array_values($filtr));

… a totéž s použitím query builderu:

$q = $flupdo->select('*')->from('table');
foreach($filtr as $k => $v) {
    $q->where("$k = ?", $v);
}
$q->execute();

A výsledný dotaz přesně jak byl vygenerován:

        SELECT *
        FROM table
        WHERE (jmeno = ?)
                AND (boty = ?)
                AND (datum = ?)

Porovnej čitelnost těch dvou kousků kódu, snadnost úprav a možnosti výskytu chyb. A ten rozdíl přenásob několika desítkami SQL dotazů v trochu větší aplikaci.

Ta knihovna není žádný bumbrlíček. Dělá totéž, jen si poradí se všemi konstrukcemi.

[Kit]

Čitelnost je podle mne srovnatelná, výsledek stejný. Nepotřebuji foreach. Na to, abych mohl místo "*" použít seznam výrazů s aliasy, musel bych tvoji knihovnu nastudovat. V případě SQL nemusím a mohu to napsat přímo. Netuším, jak bych v tom dělal subselecty, kombinaci AND/OR nebo třeba INSERT INTO ... SELECT ...

Ty sis tu knihovnu napsal sám podle svých potřeb, proto ti vyhovuje víc.

[Josef Kufner]

U takto jednoduchých věcí to srovnatelné je, u komplikovanějších už je rozdíl hodně znát. Kód jako ten tvůj mi byl motivací toto vůbec dělat. Btw, místo foreach tam máš array_map, array_keys a array_values, což mi nepřijde jako moc velké zjednodušení.

Složitější podmínky prostě napíšeš, rozsáhlé OR konstrukce jsou velmi neobvyklé a u těch malých můžeš v klidu udělat ->where('a = ? OR b = ?', $a, $b). Subselecty i insert-select by to umět mělo, nebo alespoň to bylo plánováno. A jak tak zrovna koukám, druhá možnost vypadá pravděpodobněji

Psaní SQL ta knihovna nemá nahrazovat, má ho zjednodušovat. Pokud ji použiješ, můžeš se rozhodnout, zda ten kousek budeš psát tak nebo ho necháš poskládat. Díky tomu, že se to nesnaží být nijak chytré a předávaným fragmentům SQL se to nesnaží rozumět, je chování velmi předvídatelné a snadno pochopitelné. Prostě to veme fragmenty SQL dotazu a poskládá je ve správném pořadí:

$q
    ->select('COUNT(*) AS pocet')
    ->orderBy('y ASC, z DESC')
    ->groupBy('x')
    ->having('pocet < 10')
    ->where('(SELECT ...) > ?', $c)

Míchej to dle libosti, manuál by neměl být potřeba (úvodní tutoriál se napsat ještě chystám).

[Kit]

Btw, místo foreach tam máš array_map, array_keys a array_values, což mi nepřijde jako moc velké zjednodušení.

Mohl bych použít i ten foreach, ale funkce array_* jsem si tak nějak zamiloval. Možná i proto, že se mi jeví o chlup rychlejší. Také mi nic nebrání část zmíněného kódu uzavřít do funkce nebo z toho udělat třídu, což obvykle dělám. Volání pak vypadá například takto:

$filtr = array(
    'jmeno' => 'Adam',
    'boty' => '42',
    'datum' => '2014/10/03',
);
$vysledek = $model->select(new User($filtr));

Nejčastěji však to volání vypadá poněkud jednodušeji:

$vysledek = $model->select(new User($_POST));

Konstruktor třídy User si pak funkcí array_intersect_key() vybere jen takové parametry, které se mu líbí.

Pokud bych takových proměnlivých SQL dotazů psal víc, tak bych možná nad podobnou knihovnou uvažoval, ale mám jich velmi málo. Fixní SQL dotazy v mých aplikacích převažují. Jak vidíš, tak mám volání takových dotazů ještě jednodušší.

[Kit]

... a kruci. Samozřejmě pro select používám $_GET, pro modifikující operace zase $_POST.

[Josef Kufner]

To by měl řešit router, front controller a další kopec věcí daleko od SQL dotazu

[Kit]

Však to mám důsledně oddělené. Tento kód je ve vieweru, který je volán z routeru. Třída User je v servisní vrstvě a stará se o doménu uživatelů. Do vieweru se SQL nedostane. Metody servisní vrstvy jsou volány z modelu.

[Josef Kufner]

Query builder není určen pro přímé používání z okolní aplikace. I ten má být zapouzdřen v nějakém dotazovacím objektu/metodě, které předáš filtry, podobně jak to děláš ty. Narozdíl od ORM a podobných obludností to není zamýšleno jako náhrada modelu, ale jen jako nástroj na psaní SQL dotazů uvnitř modelu.

Tedy navenek to může vypadat tak, jak jsi právě napsal, ale uvnitř místo

$pdo->query('SELECT ... WHERE ... = ?', [ ... ])

bude

$flupdo->select('...')->where('... = ?', ...)

.

Když bude filtrů pár, přínos oproti poli s WHERE podmínkami nebude velký, ale když pak chceš přidávat pro některé podmínky joiny, začnou se dít věci. To pak potřebuješ těch polí několik a udržet správně spárované parametry není vůbec jednoduché. Kdežto takový query builder už tohle všechno má v sobě a napíšeš jen:

if (isset($_POST['x'])) {
  $q->where('t1.x = ?', $_POST['x']);
  $q->leftJoin('table2 as t2 ON t2.x = t1.x AND t2.y = ?', $y);
}

Zrovna nedávno jsem sestavoval filtrovací nástroj právě pro takovéto případy. Už mne nebavilo pořád psát ty samé skoro stejné dotazy pro jen trochu jiné entity. Je to taková pěkná bestie, kde je 130 řádků dokumentace na 150 řádků kódu. Bez query builderu by to bylo celkem utrpení.