Zijn we weer terwijl ik werkelijk geen steek verder gekomen ben. Dat komt hoogstwaarschijnlijk omdat ik blijf denken over hoe ik nu alles het beste kan doen. Bedoel het werkt nu allemaal wel en dat is fijn, maar het is niet zoals ik wil.
Ik zou namelijk mijn data op willen slaan via bijvoorbeeld een UserMapper naar een DatabaseStorage de database in. Het klinkt allemaal romantischer dan het is, vooral het lezen. Voornamelijk omdat je zo ongelovelijk veel functies hebt. Neem bijvoorbeeld gewoon een MySql database, ik wil wel gebruik kunnen maken van een eventuele JOIN of DATE functie binnen SQL. Het schrijven en dergelijke lukt me nog wel om een array van te maken en uit te laten voeren. Ik heb alleen geen enkel idee voor de lees functie.
Wat ik nu gebruik
<?php
public function read($table, $columns, $id)
{
$columns = implode(', ', $columns);
# Query
$sql = "SELECT ".$columns." FROM ".$table;
# Als er een ID is
if( $id != NULL )
{
$sql .= " WHERE id = '".$id;
}
# Query Interpreteren en Controleren door Database
$stmt = $this->db->prepare($sql);
# Query Uitvoeren
$stmt->execute(array((int) $id));
# Result Opvangen en Retouneren d.m.v populate function
while ($result = $stmt->fetch(PDO::FETCH_ASSOC))
{
$data[] = $result;
}
return $data;
}
?>
Zoals je ziet kan ik dan alleen niet JOINEN. Moet ik het zoeken bij een multidimensionale array? Moet ik meerdere methods gaan maken welke dan bijvoorbeeld de MySql functies representeren? Waar zit jullie gedachte hierbij? Dat laatste haalt alleen ook weer functionaliteit weg lijkt mij?
Vind het lastige keuzes waar ik al tijden mee aan het stoeien ben.
Bedenk dat deze ene method nu alweer twee dingen aan het doen is: query maken en query uitvoeren. Trek dat als eerste uit elkaar. De methode (of zelfs class) die de query uitvoert moet op geen enkele wijze aan die query gaan lopen knoeien. Het enige dat die class doet is uitvoeren en resultaten teruggeven.
Vervolgens kan je je afvragen wat het nut is van een algemene class/methode die op basis van algemene instructies een query opbouwt. Uiteindelijk is elke query nog altijd uniek (tot op zekere hogere aangezien je de SELECT * FROM tabel queries alleen bij beginners tegenkomt) en dus zal je linksom of rechtsom ergens in je code die query moeten opbouwen. Wil je dat via allerlei abstracte instructies, of gewoon direct in tekst? Ik heb altijd voor het laatste gekozen, dus gewoon uiteindelijk elke query in een string uitgeschreven in je code. In elk geval kan je altijd elke query bouwen en het maakt het allejezus veel makkelijker om het ook nog eens te testen.
Kies je voor de abstracte querybuilder ga je dan eens alle mogelijke verschillende opties voorstellen. Een klein voorbeeldje:
- aggregate functies
- joins
- joins met meerdere voorwaarden
- subqueries
- virtuele tabellen
- virtuele kolommen
- group concats
- having clause
- group by
Kan het? Ja vast, is je code dan nog leesbaar en is het sneller (wat code bouwen betreft), ik betwijfel het ten zeerste.
Erwin, dat is inderdaad het probleem waar ik tegenaan loop. De onmogelijk vele mogelijkheden in een querie. Jij zegt dus eigenlijk dat ik mijn usermapper beter een query naar mijn storageclass kan laten sturen om dat resultaat op te halen. Zo houd ik namelijk de taken verdeeld. Maar aan de andere kant kan ik natuurlijk gewoon de query vanuit een string via PDO behandelen.
Ik denk nu even hardop en ga meteen zeggen dat dat weer niet goed is want dat zou betekenen dat bijvoorbeeld een read method 2 taken krijgt, wat dus eigenlijk niet de bedoeling is.
Wouter, ik heb momenteel het gevoel dat ik nog niet toe ben aan al het importeren van soort systemen. Ik ben nog lang niet bekwaam genoeg om ook dat te gaan begrijpen. Althans zo voel ik het.
Ik ben nog lang niet bekwaam genoeg om ook dat te gaan begrijpen. Althans zo voel ik het.
Dan is het tijd van dat gevoel af te stappen. Je bent het wel! :)
Het gebruik van dat soort tools leert je juist hoe dit soort problemen worden opgelost.
Ik denk dat elke query builder de beperkingen heeft die Erwin al aangeeft.
Ze worden ook het vaakst gebruikt door mensen die zelf geen query kunnen uitschrijven, en die komen dan in de problemen wanneer van het abstracte afgeweken moet worden.
Ik ben nog lang niet bekwaam genoeg om ook dat te gaan begrijpen. Althans zo voel ik het.
Dan is het tijd van dat gevoel af te stappen. Je bent het wel! :)
Het gebruik van dat soort tools leert je juist hoe dit soort problemen worden opgelost.
En mogelijk nog belangrijker, je leert door trial and error ook hoe/wanneer je tools niet moet gebruiken. Dat helpt in de toekomst weer de beste tool for the job te kiezen.
En de Doctrine qb heeft een oplossing voor het niet alles implementeren van query elementen. Je kan namelijk ook de ->add() functie gebruiken om een custom stukje in de query te stoppen.
