De PHPhulp kroeg
Boek MySQLi
In principe alles voor eigen gebruik.
Mijn PHP en javascript kennis is in de loop der jaren uitgebreid. Heb me daar vaker in verdiept. Maar schandelijk genoeg (ben jullie voor) niet mijn kennis mbt MySQL.
Ik gebruik nog steeds de oude mysql methode ipv mysqli of PDO.
Nu zoek ik naar een goed boek voor de mysqli methode. (Ik kies voor de mysqli methode omdat ik in principe alleen gebruik maak van SQL en niet van andere typen databases)
Wie kent een goed boek zodat ik mijn kennis kan uitbreiden?
Een van de grotere verschillen is dat MySQLi zoals prodecureel als in OO kan.
Ik denk dat als je dit doorleest, dat je dan al meer dan genoeg weet:
http://phptuts.nl/view/26/
MySQLi for beginners
(heb ik geskimd, ziet er volgens mij wel goed uit)
mijn eigen samenvatting van MySQLi
naar aanleiding van onderzoek naar de precieze werking en "tips" zoals ik mysqli zou gebruiken.
Jullie mening voor mijn situatie: Zou je je gaan verdiepen in MySQLi OO, of PDO? En waarom?
Kan nu nog beide kanten op ;)
mening:
Van welke database(s) denk je gebruik te gaan maken? Als dit enkel MySQL is zou ik voor MySQLi gaan. Het enige plausibele argument wat ik ben tegengekomen -in het geval dat je al van een MySQL database gebruik maakt- om voor PDO te gaan is wanneer je er nog niet helemaal over uit bent of MySQL de database wordt die je uiteindelijk gaat gebruiken, en wanneer er nog andere kandidaten zijn (waar PDO een driver voor heeft)
stelling:
Het is (zeer) onwaarschijnlijk dat het database type in de levensloop van een applicatie verandert.
En dan is er het (eeuwenoude?) misverstand dat PDO dit ondervangt ("Je hoeft alleen maar een handjevol PDO methodes te leren en voor de rest werkt alles he-le-maal vanzelf lololololo"). Dit doet PDO niet. Als je SQL-code in database A anders in elkaar zit dan database B dan helpt PDO je niets - PDO is een Data Access Abstraction Layer, geen Database Abstraction Layer (dit staat ook in mijn artikel...). Oftewel de code die je schrijft voor toegang tot de db (connectie, queries) is misschien wel hetzelfde tussen verschillende databases maar de vorm van de queries niet (per se). De SQL code in PDO is nog steeds (mogelijk) database-specifiek.
stelling:
PDO is niet geschreven voor MySQL. MySQLi wel. PDO heeft wel vele drivers, waaronder een MySQL driver.
mening:
Dit houdt ook in dat als je van PDO gebruik maakt om een connectie te maken met MySQL dat je misschien nog e.e.a. moet tweaken voordat dit naar behoren/verwachting werkt/reageert. Hiertoe moet je een grondige kennis hebben van zowel PDO als intrinsieke kenmerken van de database in kwestie (dus ook als je van MySQL gebruik maakt). Het is dus niet "theorie lezen and off you go met PDO" (ja, het ravijn in misschien).
mening:
Het gebruik van prepared statements wordt gepredikt, maar ik predik liever voor kennis van zaken. Ik zou nou niet direct het gebruik van prepared statements in MySQLi aanprijzen (wederom, zie mijn artikel) maar als je je gezond verstand gebruikt (en de security tips in mijn artikel volgt, lol) dan kom je een heel eind. Veiligheid van je applicatie/queries ontstaat niet door alles maar aan een toverformulie (prepare() SIMSALABIM) te voeren. Veiligheid van je applicatie/queries ontstaat door weten waar je mee bezig bent. Het enige wat PDO doet is je in slaap sussen en je lui en laks maken.
mening:
Na het schrijven van die tutorial over MySQLi voelde ik mij toch genoodzaakt om mij te verdiepen in PDO (in combinatie met MySQL). Ik moet deze nog steeds een keer afschrijven :). De dingen waar ik tegenaan liep:
- PDO lijkt typehints in bind() methoden niet te respecteren tenzij deze variabelen zelf al van dit specifieke type zijn - dit kwam mij enigszins vreemd over omdat PHP zelf loosely typed is.
Een voorbeeld: Als ik PDO vertel dat $_GET['id'] (die ik uiteraard wel filter hierop, ik ben geen complete dwaas) een integer is, dan zet PDO hier nog steeds doodleuk quotes omheen in de uiteindelijke query.
- om dit laatste waar te nemen moest ik mijn MySQL logging aanzetten en mijn uiteindelijke query uit deze log vissen, omdat ik geen andere manier heb kunnen vinden om mijn queries uit te spugen - volgens mij is dat simpelweg niet mogelijk; oftewel: queries debuggen in PDO is gigantisch omslachtig
TL;DR gebruik je enkel MySQL - gebruik MySQLi, maar snap waar je mee bezig bent door je in te lezen over de mogelijke security issues. Dat is eigenlijk ALTIJD wel een goed advies. Anders: gebruik PDO, gl & hf met queries debuggen :).
Last but not least: lees eens wat artikelen, en vorm vervolgens je eigen mening. Verdiep je in beide, en maak je eigen keuze.
EDIT: spelling
Gewijzigd op 12/02/2015 20:40:59 door Thomas van den Heuvel
Ik ga me er zeker meer in verdiepen. Maar van alles wat ik tot nu toe al had gelezen kwam ik eigenlijk al op MySQLi uit.
En wat betreft de veiligheid. Daar had ik me al in verdiept en hou ik altijd rekening mee. Data ed. die je in een query zet moet je nooit vertrouwen. Dus altijd controleren.
Quote:
Daarbij vind ik het juist een groot voordeel dat PDO verschillende drivers kent.
Dat "voordeel" wordt vaak aangehaald, maar het is niet echt een voordeel vanwege de redenen die ik eerder aanhaalde:
- je schakelt bij het gebruik / in de levensloop van een applicatie toch niet / nauwelijks tussen databases
- je kunt niet zomaar schakelen van database-types simpelweg door het wijzigen van je DSN (connectie-string), dat heeft waarschijnlijk meer voeten in de aarde dan enkel dat, daarnaast zou het niet misstaan om je applicatie(s) daarna eens grondig door te testen
- je hebt nog steeds te maken met de intrinsieke eigenschappen van de specifieke database-types; zelfs MEER dan wanneer je van een extensie gebruik maakt die specifiek geschreven is voor één type (MySQLi)
De meerwaarde hiervan is imo nihil.
Code (php)
1
2
3
2
3
<?php
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
?>
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
?>
PDO heeft wel meerwaarde. Je moet echter groter uitpakken als je PDO verkiest om meerdere databaseplatforms te ondersteunen. Je kunt dan bijvoorbeeld een driver bouwen die niet alleen de juiste PDO-driver laadt, maar ook het laden van de juiste models met queries in het SQL-dialect van een bepaalde databasestandaard regelt.
PDO kiezen voor compatibiliteit en dan alleen MySQL-specifieke queries uitvoeren in het vaak nogal typische SQL-dialect van MySQL, is inderdaad half werk. Wel is het een goed begin, maar dan moet je aansluitend nog meer stappen zetten.
Maar laten we het apparaat vooral prijzen om zijn veelzijdigheid (fantaseer hierbij een TelSell reclamespot "Wat zoveel functies? Amazing!").
Sterker nog, MySQLi kent veel meer functies dan PDO!
Bv drie manieren (preps, query en real_query) om een query uit te voeren. Op zich niet zo'n probleem, maar je moet voor elk van de drie daarop anders programeren. PDO is daarin veel eenduidiger, ongeacht of je preps of een query uitvoert, je krijgt gewoon een statement object terug.
Ook de prepared statements (die ik overigens zelden gebruik) van PDO werken beter (named paramaters ipv die afschuwelijke placeholders).
Ik persoonlijk kies dus voor PDO, niet vanwege portability maar gewoon om dat ik het beter/gemakkelijker vind werken.
Gewijzigd op 14/02/2015 13:43:19 door Ger van Steenderen
Sterker nog, er is helemaal geen "beter" of "best", zodra je deze terminologie hanteert zit je meestal al fout. Des te meer is de argumentatie waarom je kiest voor PDO of MySQLi belangrijker dan de keuze zelf. En elke keer bedient men zich weer zich van dit soort onzin argumenten. Die je overigens niet moet tellen maar moet wegen.
"Minder statements" is er ook zo een. Het is gewoon bedrieglijk dat PDO daarom makkelijker lijkt, maar het geenszins is... tenzij je stopt bij het aanleren van prepared statements en verder geen blik onder de motorkap van PDO (noch de specifieke driver) werpt.
Ik durf te wedden dat je eerder je weg vindt in MySQLi dan dat je PDO + de MySQL-driver voor PDO hebt ontleed.
Ieder zijn ding. Ik vind PDO een gribus (om bovengenoemde redenen (<-- onderbouwde argumenten yo)) en daarnaast ontiegelijk gebruiksonvriendelijk voor ontwikkeling.