MySQLi vs PDO
Ik ben eigenlijk wel benieuwd wat de mensen hier op het forum hierover zeggen:
Wat is het grootste verschil tussen MySQLi vs PDO?
Ik heb al op internet gezocht maar ik wil het van de mensen hier horen!
Ik ben benieuwd!
ik denk dat dat is dat pdo op meerdere type db werkt en mysqli alleen op (forks van) Mysql
PDO is gericht op het op een uniforme manier aanspreken van verschillende databases. mysqli is gewoon een extensie die gericht is op mysql. Wanneer je PDO gebruikt kun je in theorie eenvoudig van database wisselen. Ik zeg expres in theorie, omdat dit in de praktijk vaak tot problemen leidt.
Ik heb gehoord dat MySQLi ~2.5% sneller is en zelf vind ik het ook makkelijker werken dan PDO.
Wat zou echt een goede reden zijn om MySQLi aan de kant te schuiven en volledig over te stappen naar PDO?
Ik werk zelf met PDO omdat ik met PostgreSQL werk, ik raak MySQL niet aan tenzij er sprake is van dwang. Dan werkt PDO toch net even wat handiger.
Quote:
bronThe overall performance of all three extensions is considered to be about the same. Although the performance of the extension contributes only a fraction of the total run time of a PHP web request. Often, the impact is as low as 0.1%.
Een verschil tussen PDO en MySQLi is dat PDO een echte interface is, in de zin dat de manier van communiceren met een (ondersteund) database(type) altijd hetzelfde is. Hetgeen je vervolgens daadwerkelijk zegt tegen je database (de SQL code) is weer database-specifiek tenzij je je bedient van een Database Abstractie Laag (DAL). Het vaak genoemde voordeel van PDO boven MySQLi dat je, indien je van database schakelt, "niets nieuws hoeft te leren" gaat dus eigenlijk niet op. In de praktijk gaat dit ook niet of nauwelijks voorkomen dus dit is in zekere zin een non-argument.
Een ander verschil tussen PDO en MySQLi is dat PDO niet geschreven is voor een specifieke database, hiervoor zijn de PDO-specifieke database-drivers, zoals PDO_MYSQL. En daar zit hem de kneep: de leercurve zit helemaal niet in het handjevol klassen en methoden van PDO, maar in de configuratie en het gebruik van de specifieke database-driver. Zoals gezegd is PDO niet geschreven voor een specifieke database en is daarom op voorhand (per definitie, by design) dus ook niet afgesteld voor optimaal gebruik van een specifieke database(type).
Nog een verschil tussen PDO is dat MySQLi zowel een procedurele alsook een object georiënteerde variant heeft, terwijl PDO zich alleen van een OOP variant bedient. Ik zou trouwens geen gebruik maken van de procedurele variant van MySQLi tenzij je een knetter oud project (met mysql_ functies) moet migreren waar eigenlijk geen tijd aan besteed mag worden ofzo.
Een ander verschil is dat bij PDO je eigenlijk altijd gebruik maakt (zou moeten maken) van prepared statements, in MySQLi ben je vrij om te doen wat je wilt: je kunt zelf je queries bouwen of van de prepared statement functionaliteit in MySQLi gebruik maken. Deze laatste variant (van MySQLi) is naar mijn mening nogal brak en maakt ook echt gebruik van "prepared statements in de letterlijke betekenis van MySQL". In PDO zijn prepared statements een laag in de functionaliteit, in MySQLi maak je echt gebruik van prepared statements in-the-MySQL-sense. Dit kun je in PDO ook aanzetten door het attribuut PDO::ATTR_EMULATE_PREPARES de waarde false te geven. Dit heeft wel tot gevolg dat een SELECT statement wat je prepared en daarna execute uitmondt in de uitvoer van twee SQL-queries. Zorg dat je heel goed begrijpt hoe de driver werkt en ook hoe de MySQL-database hiermee omgaat!
Het grootste verschil in het gebruik is wat mij betreft de mate van controle die je hebt over de uiteindelijke vorm van je SQL statement (je query). Ik vind deze bij PDO niet echt fantastisch. Daarbij komt nog het volgende: ik heb tot op heden geen manier gevonden om een ge-prepared statement in PDO (dus de query in zijn uiteindelijke vorm) te debuggen anders dan de query te loggen en weer uit je log te vissen. Als je applicaties from scratch aan het schrijven bent is dat niet bepaald fijn ontwikkelen met name als je (complexe) queries moet debuggen. Als iemand hier een oplossing voor weet? Dit hoeft trouwens niet per se een bezwaar te zijn, als je applicatie is opgebouwd uit allerlei standaard componenten en je tevens je queries bouwt via zo'n DAL dan ben je zelf al niet meer bezig met het bouwen van je eigen queries maar worden deze voor je gegenereerd.
Het enige plausibele argument wat ik ooit gehoord heb om te kiezen voor PDO (i.c.m. PDO_MYSQL) boven MySQLi is als je er nog niet helemaal over uit bent welk databasetype je gaat gebruiken (noot: zit je nog steeds met de verschillende "database dialecten" bij verschillende databases tenzij je een DAL gebruikt), maar als je dan toch voor MySQL gaat zou ik kiezen voor een API die specifiek geschreven is voor deze database. Ik zou daarbij wel een interface maken voor je database, met andere woorden, toch een soort van abstractie toepassen in de communicatie met je database zodat deze functionaliteit niet 100% database specifiek (hardcoded) is. Stel dat de manier waarop PHP communiceert met MySQL-databases op een gegeven moment (weer) gaat verschuiven, dan kan dit het verschil betekenen tussen (in het gunstigste geval) het aanpassen van de implementatie van de interface, in tegenstelling tot een search en replace door je hele code van MySQLi-specifieke functies (een beetje wat nu aan de hand is met de migratie van mysql_ functies naar mysqli, daar stink je dan toch niet weer in he? :)).
Gewijzigd op 27/11/2015 23:35:20 door Thomas van den Heuvel
Ik vind het sowieso een beetje vreemd dat die verschuiving er moet zijn. Oud is niet per definitie slecht, de libpq functies die binnen PHP beschikbaar zijn zijn ook niet slecht, maar net zo oud als de mysql functies. Deprecation van de pg_ functies zit er echt nog niet in. Ik werk vooral met PDO omdat dat netjes exceptions gooit mist je dat instelt. Ik heb in het verleden een laag om de PostgreSQL errors heen gelegd om de juiste exceptions te gooien, maar dat is ook niet alles.
Meteen bij de declaratie van je connectie (creatie van een PDO object) kan het al misgaan. Exceptions die niet worden opgevangen produceren een fatal error. Als je je declaratie niet in een try-catch blok zet en het maken van een connectie mislukt (dit kan meerdere oorzaken hebben) wordt de foutmelding mogelijk op je scherm uitgespuugd. Laten die lichten die deze foutmelding verzonnen hebben nu bedacht hebben dat daarin de gegevens voor het maken van een connectie weer opgelepeld worden...
PDO lijkt ogenschijnlijk simpel, maar er zitten een heleboel addertjes onder het gras.
Super bedankt allemaal voor de informatie, ik weet genoeg!