Scriptorama.nl

Header image showing a keyboard, mouse, laptop and books on design patterns

Overstappen van de MySQL naar de MySQLi extensie

Geplaatst in: Databases, PHP op 01.05.08 door Mathieu Kooiman

2008 betekent het einde van PHP4. In augustus is het gedaan. Een van de dingen uit PHP4 die een beetje onderbelicht is gebleven bij de verschillende upgrade artikelen is het feit dat de MySQL extensie nogal oud is. De PHP ontwikkelaars zijn hier uiteraard ook mee bezig en op enkele fora kwam ik vervolgens geruchten tegen over dat de mysql extensie, de extensie die o.a. de welbekende mysql_query() functie levert, verwijderd zou worden - wat natuurlijk de nodige paniek op leverde.

Het verwijderen van de extensie lijkt wel overwogen te zijn maar de oude mysql extensie blijft gewoon bestaan in PHP6. Dus je kunt weer rustig ademhalen. Daar is niet alles mee gezegd want het is wel aan te raden om te upgraden naar MySQLi!

De MySQLi extensie is een vervanging voor de MySQL extensie maar biedt ook ondersteuning voor geavanceerdere features die sinds MySQL 4.1 beschikbaar zijn gekomen. Denk hier bij aan dingen zoals betere (fout)rapportage, prepared queries, multi queries en kennis van transactions. De oude extensie wordt niet geupdate om met deze nieuwe features te werken.

Aangezien de MySQLi extensie nieuwe features biedt is een kleine tutorial wel handig en deze heb ik een tijd geleden al eens geschreven:

Nu zijn nieuwe dingen wel leuk, maar er zijn natuurlijk ook situaties waar je al een hele bak code hebt die gebruik maakt van de oude extensie. Vrijwel alle functies die de MySQL extensie bood, biedt de MySQLi extensie ook - al hebben deze functies de prefix mysqli in plaats van mysql. In theorie is een project-wide search-and-replace (vergeet niet een backup te maken ;-) ) dus voldoende..

Een ding waar MySQLi wel verschilt van de MySQL extensie is hoe je een connectie fout kunt afhandelen. Dit doe je in de oude mysql extensie met mysql_error() maar met MySQLi gebruik je mysqli_connect_error():

PLAIN TEXT
PHP:
  1. $res = @mysqli_connect('127.0.0.1', 'user', 'password');
  2.  
  3. if (!$res)
  4. {
  5.   echo mysqli_connect_error();
  6.   exit;
  7. }

Er is overigens ook wel een MySQL-to-MySQLi converter beschikbaar die alle bestanden in een directory omschrijft van mysql functie namen naar mysqli functie namen maar deze heeft de voorkeur om m.i. vreemde code te genereren.

Ben je bezig met de upgrade van PHP 4 naar 5 of heb je behoefte aan de extra features die MySQL 4.1+ biedt: upgrade naar MySQLi!

Misschien ook interessant:

Reageer ook!

Mocht je dan toch gaan overstappen naar een nieuwe database extensie, kijk dan naar PDO! Is een stuk schaalbaarder en lekker OO :-)

Door PimNo Gravatar op 01.05.08 @ 12:31 pm | Permalink

MySQLi biedt ook een OO interface, zie de artikelen die ik heb aangehaald.

Verder weet ik niet zo wat ik moet maken van je "is schaalbaarder" opmerking. Het enige wat PDO meer biedt dan MySQLi is het feit dat dezelfde API gebruikt kan worden voor verschillende databases. Dit is voornamelijk nuttig voor de developer die, als een project om een andere database vraagt, niet nog een nieuwe set functies uit z'n hoofd hoeft te leren.

Desalniettemin is PDO zeker een fijne API - iets wat ik persoonlijk vaker gebruik dan MySQLi. MySQLi ligt echter meer in het bereik van de meeste mensen - aangezien het vrijwel de zelfde functie namen gebruikt als de MySQL extensie.

Door Mathieu KooimanNo Gravatar op 01.05.08 @ 12:41 pm | Permalink

Ik ken de OO interface van MySQLi idd. Wat schaalbaarder betreft zeg je precies wat ik bedoel. Vaak maakt een developer gebruik van hetzelfde framework voor meerdere projecten, terwijl deze projecten lang niet altijd op dezelfde database draaien.

Door PimNo Gravatar op 01.05.08 @ 5:05 pm | Permalink

> Vaak maakt een developer gebruik van hetzelfde framework voor meerdere
> projecten, terwijl deze projecten lang niet altijd op dezelfde database draaien.

Aan de keerzijde van dat verhaal zal de ontwikkelaar dan nog DB-specifieke queries moeten schrijven en het is dan de vraag of pg_query nu echt zo moeilijk te leren is. Dus nee, ik zie het niet als "schaalbaarder", al is de OO interface natuurlijk prettig.

Door berry__No Gravatar op 01.07.08 @ 10:26 am | Permalink

Tuurlijk is pg_query niet lastig te leren, maar een generieke API voor alle databases die je evt. zou toepassen op projecten heeft natuurlijk wel voordeel.

PostgreSQL heeft bijvoorbeeld, als ik bijv. http://nl3.php.net/manual/en/function.pg-execute.php bekijk, een behoorlijke andere syntax voor params in prepared queries. Dat soort geneuzel streep je dus weg met PDO en dat is wel een voordeel voor de ontwikkelaar.

Door Mathieu KooimanNo Gravatar op 01.07.08 @ 10:35 am | Permalink

> Tuurlijk is pg_query niet lastig te leren, maar een generieke API voor alle databases die je evt. zou toepassen op
> projecten heeft natuurlijk wel voordeel.

Dat zeg ik: de OO interface is natuurlijk prettig. Maar schaalbaarder?

Door berry__No Gravatar op 01.07.08 @ 10:51 am | Permalink

Ben ik even blij dat ik al een tijd PDO gebruik :)

Door MartenNo Gravatar op 01.07.08 @ 11:28 am | Permalink

@berry__ Ik denk zeker dat het je applicatie/framework schaalbaarder maakt met het gebruik van PDO. Denk ook aan overdraagbaarheid naar nieuwe/vervangende programmeurs. Er is nu maar 1 syntax wat de boel een stuk makkelijker maakt.

Door PimNo Gravatar op 01.14.08 @ 12:55 pm | Permalink

Pim, dat kan je beter flexibiliteit of eenvoud noemen. ;)

De database is juist doorgaans het minst schaalbare onderdeel en de ideale oplossing om db's schaalbaar te maken bestaat nog niet.

Door MaartenNo Gravatar op 01.14.08 @ 3:25 pm | Permalink

RSS feed for comments on this post.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>