[PHP] Full query in model ?

[Verwijderd]

Ik ben erg gegrepen door MVC en tevens ook door PDO !

Nu is PDO eigenlijk een ontzettend fijne wrapper alleen kan je met een eigen wrapper je manier van gebruik nog verder versimpelen.

Nu heb ik een aantal functies gemaakt welke het schrijven van een query in het model eigenlijk overbodig maken, ik vrvaag me alleen af of het wel duidelijk is voor de toekomst.

in een model functie kun je bijvoorbeeld doen:

code:

function userinfo($username) {
        $sql = "SELECT * FROM users WHERE username LIKE $username";
        
        return parent::queryFirst($sql);

}

Hierdoor krijg je de eerste rij terug van je query omdat de queryFirst functie limit op 1..


Nu dacht ik dat je eigenlijk ook één en de zelfde query functie kunt schrijven welke je in zijn doen aanpast in de functie-variabelen.

code:

function userinfo($username) {
        
        return parent::select("*","users",$username,fetch_column);
        
        }

Dit is even een zeer ruige opzet, maar ik denk dat het idee wel duidelijk is.

Opzich zal een query schrijven en deze uitvoeren in het model duidelijker zijn, maar zou de 2e methode niet veel makkelijker zijn op lange termijn als je kijkt naar hoeveel verschillende query functies je moet schijrven als zijnde:

• execute($sql, $params = array()) – Execute a statement and returns number of effected rows
• getValue($sql, $params = array()) – Execute a statement and returns a single value
• getRow($sql, $params = array()) – Execute a statement and returns the first row as array
• getResult($sql, $params = array()) – Execute a statement and returns row(s) as 2D array
• getLastInsertId($sequenceName = “”) – Returns the last inserted id

Bovenstaand zijn wat voorbeelden welke functies zijn welke simpel met een volledig geschreven query gebruikt kunnen worden. Ik vraag me dus af of die "extra" query wel nodig is als het echt "handig" aanpakt

[flashin]

Als ik het duidelijk begrijp wil je ipv SQL schrijven een query-builder maken?

SQL is in principe een gestandaardiseerde taal. Je bouwt zo een algemenere data wrapper ipv een database wrapper. PDO is al aardig geabstraheerd heeft die functies in principe ook aangezien er diverse drivers zijn.
Als jij het efficienter vindt werken omdat je zo 100x minder moet typen, waarom niet. Het heeft verder niet veel functie denk ik.

[ Voor 101% gewijzigd door flashin op 10-11-2009 20:33 ]

[Verwijderd]

flashin schreef op dinsdag 10 november 2009 @ 20:27:
Als ik het duidelijk begrijp wil je ipv SQL schrijven een query-builder maken?

Dat is inderdaad het plan

SQL is in principe een gestandaardiseerde taal. Je bouwt zo een algemenere data wrapper ipv een database wrapper. PDO is al aardig geabstraheerd heeft die functies in principe ook aangezien er diverse drivers zijn.
Als jij het efficienter vindt werken omdat je zo 100x minder moet typen, waarom niet. Het heeft verder niet veel functie denk ik.

Tja functie, ik denk dat het minder typen en sneller je code schrijven toch wel een toegevoegde waarde heeft en wellicht toch wel een functie.

[RobertMe]

Hoe ga je dit doen met ingewikkeldere query's (subqueries, joins, etc, etc)? Dit kun je never nooit (volledig) handhaven. Bovendien kost het je gewoon performance, elke keer de query dynamisch opbouwen is gewoon langzamer dan de query een keer uittypen, je maakt de query toch maar een keer.

Wat ik zelf doe is nog een laag "achter" de M plakken, het is de taak van deze laag om met de DB te communiceren, oftewel, daarin staan de query's etc. Vervolgens spreekt mijn M (indien nodig) de DB laag aan. Indien nodig omdat je soms de DB niet nodig hebt, en andere keren wil je niet dat de M met de DB laag communiceert, omdat het onzinnig is, je gaat bijvoorbeeld niet aan je User vragen om alle users terug te geven, dat wil je gewoon rechtstreeks bij je DB laag doen.

[Gomez12]

Verwijderd schreef op dinsdag 10 november 2009 @ 20:39:
[...]


Tja functie, ik denk dat het minder typen en sneller je code schrijven toch wel een toegevoegde waarde heeft en wellicht toch wel een functie.

Tja, ik zou er nog eens goed over nadenken of je echt 80% van je query's met je 1e opzet gaat kunnen uitvoeren of dat je gewoon een extra moloch creeert die telkens uitgebreid moet worden nav nieuwe query's / joins etc waardoor je alle tijdswinst voor typen ruimschoots verliest met het bijhouden van je eigen abstractie laag.

Er zijn al 100én database abstractie lagen, omdat je volgens mij nog in het begin van je project zit zou ik eerst eens goed gaan kijken of er niet 1 daarvan voldoet voordat je aan iets als dit begint.

Je query's worden over het algemeen enkel maar ingewikkelder, dit vereist steeds meer extra werk aan je abstractie laag. Terwijl er al abstractie lagen zijn waar gewoon x maanden / jaren werk in zit.

[Verwijderd]

RobertMe schreef op dinsdag 10 november 2009 @ 21:01:
Hoe ga je dit doen met ingewikkeldere query's (subqueries, joins, etc, etc)? Dit kun je never nooit (volledig) handhaven. Bovendien kost het je gewoon performance, elke keer de query dynamisch opbouwen is gewoon langzamer dan de query een keer uittypen, je maakt de query toch maar een keer.

Ben ik met je eens, dat wordt een lastige zaak. Was ik me wel van bewust maar nog niet in mijn lijstje geschreven dus ik keek ik hier overheen.

Wat ik zelf doe is nog een laag "achter" de M plakken, het is de taak van deze laag om met de DB te communiceren, oftewel, daarin staan de query's etc. Vervolgens spreekt mijn M (indien nodig) de DB laag aan. Indien nodig omdat je soms de DB niet nodig hebt, en andere keren wil je niet dat de M met de DB laag communiceert, omdat het onzinnig is, je gaat bijvoorbeeld niet aan je User vragen om alle users terug te geven, dat wil je gewoon rechtstreeks bij je DB laag doen.

Dit doe ik ook dit is mijn modelbase bestand, dus ik denk dat we op dezelfde weg zijn.

[Verwijderd]

Ik heb zelf wel eens ene poging gedaan om iets dergelijks te maken, zou deze eventueel nog wel op kunnen zoeken. Maar uiteindelijk is dat hem voor mij niet geworden, ingewikkelde queries met een aantal joins met alle voorwaarden hiervan en dergelijke blijven voor mij toch makkelijker om zelf te typen. Dit in combinatie met PDO::prepare().

Maar ik ben benieuwd naar 't verdere verloop van dit topic. /me bookmarked..

[Verwijderd]

Verwijderd schreef op dinsdag 10 november 2009 @ 21:15:
Ik heb zelf wel eens ene poging gedaan om iets dergelijks te maken, zou deze eventueel nog wel op kunnen zoeken. Maar uiteindelijk is dat hem voor mij niet geworden, ingewikkelde queries met een aantal joins met alle voorwaarden hiervan en dergelijke blijven voor mij toch makkelijker om zelf te typen. Dit in combinatie met PDO::prepare().

Maar ik ben benieuwd naar 't verdere verloop van dit topic. /me bookmarked..

Nou er zijn wel leuke wrappers welke de execute voor je doen, dit had ik eerst als basis ook geschreven namelijk.

Opzich eigenlijk gewoon functies waar je ook nog een fetch-mogelijkheid kan zetten bij een van de versies.

Ik denk dat dat het uiterste is wat je kunt doen in flexibiliteit en bruikbaarheid.

[RobertMe]

Verwijderd schreef op dinsdag 10 november 2009 @ 21:12:
[...]


Dit doe ik ook dit is mijn modelbase bestand, dus ik denk dat we op dezelfde weg zijn.

Ik denk het niet. Je model is je daadwerkelijke object. Een User object heeft als attributen de eigenschappen van een user, en als methoden de acties die je op een user kunt doen (denk aan bewerken, account activeren, etc, etc). Hierbij hoort dus niks van opslag etc (opslag staat dan ook helemaal niet in MVC beschreven). De communicatie met de database moet je dus ergens anders regelen, vervolgens zal je M (of C) met de DB laag communiceren, en die (db laag) zal uiteindelijk zelf query's gaan uitvoeren. Wat bijvoorbeeld als je dadelijk niet in een database wil opslaan, maar in files? Of je niet meer (lokaal) gaat opslaan, maar over een SOAP interface gaat communiceren en die de opslag regelt? Dan moet je dus overal vanalles gaan aanpassen. Ik vraag aan mijn "provider" class, geef me user met id X terug, en dat doet ie dan ook, hoe die dat doet, I don't care, als ie het maar doet.

Uit je voorbeeld is parent::queryFirst ook een mooie, je User is dus een subclass (extend) van een of andere DB class. Terwijl je extend betekend "is een" Laptop extends Computer (laptop is een computer), maar User is geen database, dus ook geen extend.

[Cartman!]

Beetje n dooddoener wellicht, maar kijk eens naar Zend_Db of Doctrine. Die bevatten ook een eigen querybuilder waar je ook 'lastige' dingen als joins simpel kunt uitvoeren.

PHP:

$select = $this->select();
$select->from('tabel1', array('veld1', 'veld2'));
$select->joinLeft('tabel2', 'tabel1.veld1 = tabel2.veld1', array('tabel2_veld1' => 'veld1', 'veld3'));
$select->where('tabel1.veld1 = ?', 'iets');
$select->limit(15);

return $this->fetchAll($select);

zoiets (meer voorbeelden voor Zend_Db op deze ref. pagina: http://framework.zend.com...l#zend.db.select.building )

[mithras]

Je moet allereerst goed gaan begrijpen waar je uiteindelijk heen wilt. Er zijn verschillende patterns er daarbij verschillende mogelijkheden. Cartman! geeft al wat hints, maar hier nog een paar

Allereerst is het belangrijk of je een active record / ORM achtig systeem wil plaatsen of meer naar een service layer met een domain model. Voor het eerste, daar ga je erg naar Doctrine toe. De tweede, dat gebruik Zend_Db. Maar Zend_Db heeft ook meer, zoals een query builder die Cartman! laat zien.

Ik gok dat je wel wat weet over ORM, maar weinig over een service layer met een domein model. Daarom dit plaatje:

Wat jij dus hebt is aan de ene kant je model in de service layer, maar daarbinnen wil je ook direct het domain model implementeren. Imho lijkt me dat niet verstandig. Je kan gemakkelijker daarvoor een data mapper gebruiken. Even een outline van dat laatste:

PHP:

class User
  public $id;
  public $name;
  protected $_mapper;

  public function getMapper ()
  {
    if (null === $this->_mapper) {
      $this->_mapper = new UserMapper;
    }
    return $this->_mapper;
  }

  public function find ($id)
  {
    $this->getMapper()->find($id, $this);
  }

class UserMapper
{
  public function find ($id, User $user)
  {
    $row = $this->doSomethingToFindUserWithId($id)->current();
    $user->id = $row->id;
    $user->name = $row->name;
  }
}

Hierbij splits je dus je model met je feitelijke opslag. Wil je later je User opslaan in xml, dan kan dat gewoon. Het is slechts een deel herschrijven. Maar dit gaat misschien té offtopic.

Concreet: wat je wil is waarschijnlijk een query builder. Maar kijk uit, ik zou eerst kijken naar een functionele tussenlaag en dan pas gaan nadenken over hoe je queries gaat opbouwen

[Gomez12]

mithras schreef op dinsdag 10 november 2009 @ 22:21:
Wat jij dus hebt is aan de ene kant je model in de service layer, maar daarbinnen wil je ook direct het domain model implementeren. Imho lijkt me dat niet verstandig. Je kan gemakkelijker daarvoor een data mapper gebruiken.

...

Hierbij splits je dus je model met je feitelijke opslag. Wil je later je User opslaan in xml, dan kan dat gewoon. Het is slechts een deel herschrijven. Maar dit gaat misschien té offtopic.

Concreet: wat je wil is waarschijnlijk een query builder. Maar kijk uit, ik zou eerst kijken naar een functionele tussenlaag en dan pas gaan nadenken over hoe je queries gaat opbouwen

Goede overdenking, maar pas er wel voor op dat je iets niet gaat overdesignen.

Het is altijd een afweging tussen beheer versus speed. Hoe meer lagen je er tussen stopt hoe makkelijker het aanpassen / beheer is ( zoals al gezegd, een xml laag is er zo tussen te vrotten ) maar het creeert allemaal overhead.
Bij een groter project is die speed-overhead totaal niet relevant ( dan koopt de klant maar betere hardware, hw is goedkoper dan programmeeruren ), maar ik ken ook genoeg simpele projecten die juist niet vooruit te branden zijn omdat ze theoretisch overal snel in te zetten zijn maar in de praktijk enkel 1 ding doen en de rest van de code gewone pure overhead is.

Voor een simpel tellertje op een website wat met een query te doen is heb je geen fancy stuff nodig.
Voor een cms heb je het juist weer wel nodig ( een xml / rss / excel import / export wordt dan enkel 1x een definitie maken en alles werkt ermee )

[Bergen]

Ik hou er wel van om het model van de volgende site te gebruiken:
http://www.odi.ch/prog/design/php/guide.php

Eigenlijk is het de inrichting van het model en de controller van het MVC patroon. Binnen het Model maak je gebruik van Data Access Objects (DAO's). Die bepaalt aan de hand van een Value Object (een klasse met alleen maar gegevens, in de vorm van de tabel waar de DAO voor gebouwd is, zie artikel) wat voor query er gebouwd wordt, genereert eventueel zelf nieuwe VO's etc.

Mijn variant hierop is dat er zo weinig mogelijk door de klasse specifieke DAO wordt gedaan, maar dat er zoveel mogelijk dynamisch in een abstracte BaseDAO wordt gedaan. Voor user info zou je bijvoorbeeld een UserInfoDAO kunnen schrijven, waarin alleen de tabelstructuur wordt gedefinieerd. De UserInfoDAO extends de BaseDAO, die vervolgens de structuur in de UserInfoDAO gebruikt om de queries te bouwen. Hopelijk is het een beetje duidelijk.

Wel moet ik vermelden dat ik geen 'ingewikkelde' dingen zoals subqueries, joins, etc gebruik binnen PHP. (De tools die ik schrijf zijn daar te 'straightforward' voor.) Alleen de basis inserts, updates, deletes en selects gebruik ik.

[ Voor 10% gewijzigd door Bergen op 11-11-2009 01:10 . Reden: 'het' model, niet 'de' model :P ]

[Verwijderd]

Bergen schreef op dinsdag 10 november 2009 @ 23:20:
Ik hou er wel van om het model van de volgende site te gebruiken:
http://www.odi.ch/prog/design/php/guide.php

Is wel een beetje gedateerd zo te zien, aan de layout en voorbeelden te zien. Verder inhoudelijk ziet het er wel aardig uit, mits het alleen om het idee gaat.

[Bergen]

Ja, maakt niet zoveel uit hoe oud de site is... Het gaat om het idee/patroon en dat is nooit gedateerd. Het gaat om het idee en hoe je het implementeert in je eigen project. Overigens bedoelde ik ook alleen het stuk over controller/logic/dao/vo, de rest van die pagina boeit me niet echt.

Ik vind dat door de scheiding van controller/logic/vo/dao een project heel helder van opzet wordt. Het biedt ook goeie debugmogelijkheden, omdat je door de duidelijke scheiding snel kunt concluderen waar je een fout moet zoeken. En om on-topic te blijven: het automatisch genereren van queries vind ik goed te doen binnen dit systeem.

[ Voor 21% gewijzigd door Bergen op 11-11-2009 01:15 ]

[Verwijderd]

Cartman! schreef op dinsdag 10 november 2009 @ 21:47:

PHP:

$select = $this->select();
$select->from('tabel1', array('veld1', 'veld2'));
$select->joinLeft('tabel2', 'tabel1.veld1 = tabel2.veld1', array('tabel2_veld1' => 'veld1', 'veld3'));
$select->where('tabel1.veld1 = ?', 'iets');
$select->limit(15);

return $this->fetchAll($select);

Het ontgaat mij even, maar wat is het nu het praktisch nut van deze notatie? Ik kan alleen maar nadelen verzinnen...

[RedHat]

Ik vind het altijd véél overzichtelijker om query's voluit te schrijven. Dan zie ik in één oogopslag wat er gebeurd, om welke data het gaat etc.

[Cartman!]

Verzin d'r eens een paar dan?

Een paar pro's:
- makkelijk onderhoudbaar
- portable naar andere adapters (oracle, mysql, postgresql)
- niet nodig zelf queries te typen -> minder fouten

[Creepy]

Cartman! schreef op woensdag 11 november 2009 @ 11:58:
Verzin d'r eens een paar dan?

Een paar pro's:
- makkelijk onderhoudbaar

Vindt je? Ik zie meer code staan op deze manier

- portable naar andere adapters (oracle, mysql, postgresql)

True, maar dat is ok op andere manieren te realiseren

- niet nodig zelf queries te typen -> minder fouten

Je schrijft nog gewoon een query hoor, alleen de notatie is anders. Sorry, maar ik zie hier echt geen voordelen in. Gebruik dan gewoon direct iets als LLBLgen of (n)hibernate

[armageddon_2k1]

Creepy schreef op woensdag 11 november 2009 @ 12:01:
[...]

Vindt je? Ik zie meer code staan op deze manier

Ik vind minder code echt niet altijd beter onderhoudbaar. Soms kan meer code (met mate) mijn inziens er wel voor zorgen dat iets onderhoudbaarder en overzichtelijker is.

CodeIgniter framework gebruikt een zelfde manier van database-queries en het heeft het voor mij in ieder geval een stuk makkelijker en onderhoudbaarder gemaakt.

True, maar dat is ok op andere manieren te realiseren

Ja, dus? Dit is dan toch ook 1 van de manieren? Waarom zou dit dan niet kunnen?

Je schrijft nog gewoon een query hoor, alleen de notatie is anders. Sorry, maar ik zie hier echt geen voordelen in. Gebruik dan gewoon direct iets als LLBLgen of (n)hibernate

In PHP heeft het mij wel gered, omdat ie rare quirks tussen verschillende DB engines opvangt als ik op deze manier queries maak. Ik heb zojuist een API gemaakt in CodeIgniter welke request afhandeld op een database en deze returned in JSON. Zonder enige moeite werkte dit op MySQL, MSSQL en zelfs op een verdwaalde ODBC connectie, terwijl de queries wezenlijk verschillen. Dan doet dit toch gewoon z'n werk?

[ Voor 44% gewijzigd door armageddon_2k1 op 11-11-2009 12:13 ]

[mithras]

Creepy schreef op woensdag 11 november 2009 @ 12:01:
[...]

Vindt je? Ik zie meer code staan op deze manier

[...]

Je schrijft nog gewoon een query hoor, alleen de notatie is anders. Sorry, maar ik zie hier echt geen voordelen in. Gebruik dan gewoon direct iets als LLBLgen of (n)hibernate

Wat ik hét grote voordeel aan de querybuilder van Zend vind, is de mogelijkheid ze te nesten:

PHP:

/** 
 * Stelt tabel voor in db
 */
class Model_DbTable_User extends Zend_Db_Table_Abstract
{
  protected $name = 'users';
}

/**
 * Mapper voor model <-> database
 */
class Model_UserMapper
{
  protected $_dbTable;
  public function getDbTable ()
  {
    if (null === $this->_dbTable) {
      $this->_dbTable = new Model_DbTable_User;
    }
    return $this->_dbTable;
  }

  public function fetchAll ()
  {
    $rowset = $this->getDbTable()->fetchAll();
    // do things with $rowset
    return $result;
  }

  public function fetchAllActive ()
  {
    $where = $this->getDbTable()->select()->where('active = 1');
    $rowset = $this->getDbTable()->fetchAll($where);
    // do things with $rowset
    return $result;
  }
}

Dus verder geen omkijken naar. Je kan op deze manier een klein gedeelte van de query schrijven, injecten in een algemenere vorm en dat wordt gecombineerd. Dit geeft je uiteindelijk best grote voordelen op in onderhoudbaarheid en overzichtelijkheid van de code

[Verwijderd]

Cartman! schreef op woensdag 11 november 2009 @ 11:58:
Verzin d'r eens een paar dan?

- Introductie van nieuwe query notatie terwijl SQL aardig bij programmeurs is ingeburgerd. Je introduceert dus een drempel.
- Je ontneemt de mogelijkheid tot query optimalisatie. Het op een andere manier opschrijven van een query kan enorme verschillen geven in performance.
- Er wordt geen werk uithanden genomen en dat is bij mij een zwaarwegende voorwaarde om een framework te introduceren.

[Cartman!]

Creepy schreef op woensdag 11 november 2009 @ 12:01:
[...]

Vindt je? Ik zie meer code staan op deze manier

[...]

True, maar dat is ok op andere manieren te realiseren

[...]

Je schrijft nog gewoon een query hoor, alleen de notatie is anders. Sorry, maar ik zie hier echt geen voordelen in. Gebruik dan gewoon direct iets als LLBLgen of (n)hibernate

Ik zie anders ook geen enkel argument om het niet te gebruiken anders, kom daar eens mee dan? Vooral dat de ene meer gewend is aan oracle-smaak en de ander aan mysql-smaak doet er met een querybuilder niet meer toe, je schrijft allemaal dezelfde portable queries.

LLBLgen op PHP? hibernate op PHP? Laat eens zien dan...


edit:

Verwijderd schreef op woensdag 11 november 2009 @ 12:16:
[...]

- Introductie van nieuwe query notatie terwijl SQL aardig bij programmeurs is ingeburgerd. Je introduceert dus een drempel.

Het is gewoon programmeren terwijl je niet perse SQL kennis hoeft te hebben, wordt voor je geregeld. En elke gemiddelde programmeur kan met objecten werken, het is leesbaar en overduidelijk.

- Je ontneemt de mogelijkheid tot query optimalisatie. Het op een andere manier opschrijven van een query kan enorme verschillen geven in performance.

Mocht je dat perse willen kun je het altijd nog voluit schrijven maar in principe kun je door andere methods te gebruiken in de querybuilder de query ook zo schrijven.

- Er wordt geen werk uithanden genomen en dat is bij mij een zwaarwegende voorwaarde om een framework te introduceren.

Vind ik wel, ik ben zo minder tijd kwijt aan het maken van queries, alles wordt automatisch escaped, geen syntax foutjes meer dus minder tijd kwijt aan debuggen.

[ Voor 42% gewijzigd door Cartman! op 11-11-2009 12:21 ]

[zwippie]

Hier ook een Zend_Db gebruiker.
Ik vind het zelf vrij gemakkelijk om zo queries te bouwen, om bijvoorbeeld optionele where clausules of joins toe te voegen ver nadat je je 'basis' query al hebt gemaakt. Dat is wat mij betreft het sterkste punt van dit systeem; makkelijker en overzichtelijker queries opbouwen.

Ik snap het argument dat het eigenlijk alleen maar een laagje suiker om je sql is, maar suiker is nou eenmaal lekker.

[orf]

Het grote voordeel van je queries op deze manier opbouwen is dat je dynamisch bijvoorbeeld extra WHERE's toe kunt voegen. Als je zelf je queries schrijft moet je dat met string concatting doen, moet je kijken of er AND of WHERE gebruikt moet worden, etc.

[ Voor 0% gewijzigd door orf op 11-11-2009 12:24 . Reden: Zwippie was me voor... ]

[Verwijderd]

zwippie schreef op woensdag 11 november 2009 @ 12:21:
Ik vind het zelf vrij gemakkelijk om zo queries te bouwen, om bijvoorbeeld optionele where clausules of joins toe te voegen ver nadat je je 'basis' query al hebt gemaakt. Dat is wat mij betreft het sterkste punt van dit systeem; makkelijker en overzichtelijker queries opbouwen.

Ja dat vind ik wel een sterk argument. Ik vind het overigens niet sterk genoeg te opzichte van de nadelige punten. Dat is dan natuurlijk wel voornamelijk gebaseerd op referenties die ik dan weer maak aan projecten waarop ik werkzaam ben. De casus dat ik een basis query heb waarop ik een paar varianten maak komt simpelweg niet al te vaak voor.

[RobertMe]

Cartman! schreef op woensdag 11 november 2009 @ 11:58:
- makkelijk onderhoudbaar

Vind ik niet, omdat je met functie calls, array's etc op een regel zit te werken krijg je een enorme puinhoop van php code, en de dingen die je in de query wil hebben (array('kolom1', 'kolom2', 'kolom3') vs. kolom1, kolom2, kolom3 scheelt me ook nog eens een hoop accentjes, dus minder kans op typefouten/vergeten)

- portable naar andere adapters (oracle, mysql, postgresql)

Owja? Ook ingewikkelde query's of query's die alleen op een specifieke db kunnen? Bij PostgreSQL gebruik ik INSERT INTO ... RETURNING ... zodat ik meteen het id en eventuele default waardes kan ophalen. Heeft Zend 1. ook ondersteuning voor dit soort query's? en 2. vangt hij dit voor MySQL af door een SELECT erna te draaien?

- niet nodig zelf queries te typen -> minder fouten

Zoals ik hierboven al aangaf bij makkelijker onderhoudbaar, ik vind het er maar onoverzichtelijk uit zien, en omdat je alles/veel als array hebt, mis je al snel een ( of ' etc.

[Cartman!]

RobertMe schreef op woensdag 11 november 2009 @ 12:28:
[...]

Vind ik niet, omdat je met functie calls, array's etc op een regel zit te werken krijg je een enorme puinhoop van php code, en de dingen die je in de query wil hebben (array('kolom1', 'kolom2', 'kolom3') vs. kolom1, kolom2, kolom3 scheelt me ook nog eens een hoop accentjes, dus minder kans op typefouten/vergeten)

Mijn IDE geeft dat automatisch al aan, dat kom ik dus tijdens het typen al tegen. En hoe jij regels en wellicht arrays afbreekt is gewoon een kwestie van codestandaard, gewoon netjes programmeren imo.

Owja? Ook ingewikkelde query's of query's die alleen op een specifieke db kunnen? Bij PostgreSQL gebruik ik INSERT INTO ... RETURNING ... zodat ik meteen het id en eventuele default waardes kan ophalen. Heeft Zend 1. ook ondersteuning voor dit soort query's? en 2. vangt hij dit voor MySQL af door een SELECT erna te draaien?

Als je querys probeert op te bouwen op een adapter wat niet ondersteund wordt dan krijg je netjes een exception. Maar meestal hebben de methods van de adapters dus juist dergelijke zaken al juist geimplementeerd.

Zoals ik hierboven al aangaf bij makkelijker onderhoudbaar, ik vind het er maar onoverzichtelijk uit zien, en omdat je alles/veel als array hebt, mis je al snel een ( of ' etc.

Zie ook mijn punt 1, gebruik een goede ontwikkelomgeving. Als je dagelijks veel programmeert zul je naar mijn idee sowieso maar weinig syntaxfouten maken. Misschien verschilt dat van persoon tot persoon

Het punt van zwippie is inderdaad erg sterk. Je kunt heel snel door ff een regel te commenten een where weglaten waar je anders je query zelf moet aanpassen, echt enorm handig.

[ Voor 3% gewijzigd door Cartman! op 11-11-2009 13:02 ]

[Creepy]

Cartman! schreef op woensdag 11 november 2009 @ 12:18:
[...]

Ik zie anders ook geen enkel argument om het niet te gebruiken anders, kom daar eens mee dan? Vooral dat de ene meer gewend is aan oracle-smaak en de ander aan mysql-smaak doet er met een querybuilder niet meer toe, je schrijft allemaal dezelfde portable queries.

LLBLgen op PHP? hibernate op PHP? Laat eens zien dan...

Dan zoek je iets zoals LLBLgen of hibernate voor PHP? Er bestaan toch wel van dat soort libs voor PHP lijkt me? Niet zo letterlijk nemen, er staat in mijn zin dan ook "zo iets als LLBLgen of ...."

Je draait overigens het argument om. Er worden argumenten gegeven om het wel te gebruiken en die zijn voor mij allemaal niet voldoende. Dat is al genoeg reden om niet iets nieuws te gaan introduceren omdat het naar mijn idee geen toegevoegde waarde heeft.

Het is gewoon programmeren terwijl je niet perse SQL kennis hoeft te hebben, wordt voor je geregeld. En elke gemiddelde programmeur kan met objecten werken, het is leesbaar en overduidelijk.

En dat is nu juist ook mijn punt: libs zoals LLBLgen, hibernate (of een andere ) zorgen hier ook gelijk voor. Hoef je niet eens meer een omzetting te doen van het resultaat van de query naar de juiste classes (of andersom), ook dat wordt dan voor je regelt.

[ Voor 20% gewijzigd door Creepy op 11-11-2009 13:07 ]

[Cartman!]

Wat zijn dan de belangrijke verschillen tussen LLBLgen/hibernate en Zend_Db/Doctrine?

En naar mijn idee draai jij t nu om, je geeft naar mijn mening niet echt een sterk tegenargument op mijn argumenten ("ik vind het meer code", "ja, eens" en "je schrijft nog steeds queries" (duh, querybuilder)). Dat jij het geen toegevoegde waarde vind hebben betekent natuurlijk niet dat het daarmee een slecht systeem is. Zo doe je het wel overkomen.

[Creepy]

Doctrine is precies wat ik bedoel: een ORM (zoiets als LLBLGen of Hibernate ). En dat is wel wat meer dan alleen een query builder.

Zend DB gaat wat mij betreft niet ver genoeg voor zover ik dat nu zie. Dat lijkt alleen een query builder te zijn en ik zie hier alleen ook voorbeelden van een querybuilder staan. En alleen een query builder voegt voor mij erg weinig toe (je "ja duh, querybuilder" vat dat ook mooi samen). Neem de argumenten van Mark Platvoet even mee, die vat mooi samen waarom ik geen query builder zou gebruiken.

[ Voor 10% gewijzigd door Creepy op 11-11-2009 13:19 ]

[Cartman!]

Naar mijn idee vroeg de TS om informatie over querybuilding, niet over ORM dus dat heb ik even niet meegenomen in de discussie. Zend_Db heeft een iets andere opzet dan Doctrine inderdaad maar is zover ik weet ook meer dan alleen een querybuilder (ik gebruik momenteel een ORM systeem van een collega, een uitbreiding op Zend_Db die lekker werkt, binnenkort gaan we over op Doctrine).

[cariolive23]

Het probleem met een query-builder is dat 80% van de queries dermate eenvoudig is dat het niets toevoegt om deze met PHP (of een andere taal) te laten bouwen (met plain SQL ben je sneller klaar) en dat de resterende 20% te ingewikkeld is om met een query-builder te laten bouwen waardoor je deze alsnog zelf moet schrijven. Het voegt dus niets toe (te eenvoudig) of het werkt niet (te complex).

En performance, dat is voltooid verleden tijd. Vergeet het maar, je hebt nauwelijks controle over de queries die worden uitgevoerd en optimaliseren wordt een bijzonder lastige opgave.

[Freeaqingme]

Cartman! schreef op woensdag 11 november 2009 @ 13:23:Ik gebruik momenteel een ORM systeem van een collega, een uitbreiding op Zend_Db die lekker werkt, binnenkort gaan we over op Doctrine.

Geheel offtopic; maar als ik jou was zou ik nog even wachten daar mee. Zend en Doctrine hebben namelijk besloten samen te gaan werken, iets waardoor (mede) de ontwikkeling van ZF's eigen ORM gestopt is. Het idee is om je Doctrine Models automatisch te laten genereren door Zend_Tool en Doctrine (of iig de variant in ZF) gebruik te laten maken door de Zend_Db adapter, Zend_Filter filters, en wellicht Zend_Validate validators. Zie ook http://framework.zend.com...ration+-+Benjamin+Eberlei

Wat het gebruik van Zend_Db_Select betreft; dit heeft inderdaad het voordeel dat je makkelijk je query kan uitbreiden op allerlei fronten. Maar het zorgt er niet echt voor dat je later makkelijk van RDBMS kan wisselen. Immers, ieder RDBMS gebruikt z'n eigen functie namen, etc, waardoor je alsnog al je queries langs moet lopen.

Hoewel het uitwisselen van RDBMS een veelgehoord argument is voor DAL's, ben ik nou eigenlijk nog nooit iemand tegengekomen die op een willekeurige dag even van RDBMS wisselde...