@mugaru dit is mogelijk best een handige tool voor het werk wat het doet, maar lost andere (bijvoorbeeld de eerder genoemde) problemen niet op (denk aan algehele opbouw en werkwijze van pagina's / stukken code).

Daarnaast bega je in zekere zin dezelfde "fout" opnieuw: vanaf PHP 7 is de oorspronkelijke MySQL-driver verdwenen, en hiermee alle mysql_* functies. Het is logisch dat als je dan met dezelfde codebase verder wilt dat deze functies vervangen moeten worden. Maar wat doe je dan als je deze tool gebruikt? Je verandert daarmee alle instanties van mysql_* naar een mysqli_* variant, mogelijk met extra of verwisselde parameters.

Maar wat je hier wederom doet is hardcoding van de databaseoplossing. Dit zal natuurlijk altijd in zekere mate het geval zijn omdat en zolang je rechtstreeks (mogelijk database-specifieke) SQL in je code zet, en dus geen gebruik maakt van een Database Abstraction Layer (DAL). Toch valt er iets te zeggen om -op zijn minst- een Database Access Abstraction Layer (DAAL) te gebruiken. Want wie zegt dat er op den duur niet opnieuw dingen veranderen in MySQL-land?

Het voordeel hiervan is een -weliswaar gedeeltelijke- ontkoppeling van specifieke database-gerelateerde functies en methoden zodat wanneer (niet als maar wanneer :)) er iets wijzigt, je -in het ideale geval uiteraard- enkel de implementatie van deze code hoeft te veranderen, en verder inhoudelijk geen letter applicatiecode hoeft aan te passen.

Een ander voordeel is dat je dingen kunt vereenvoudigen en opdrachten kunt bundelen zodat je gemakkelijker kunt werken met de desbetreffende database. Dit bespaart je dus op den duur ook tijd.

Wat ik in wezen voorstel is dat je, en eigenlijk iedereen die van plan is om met MySQL te werken, er verstandig aan doet om een soort van wrapper om je database-interactie te schrijven (maar misschien nog beter is een DAL uiteraard, omdat je daarmee dit helemaal loskoppelt van het gebruik. Dit is wel een tradeoff, het introduceert overhead, abstractie en complexiteit, en de vraag is of het dat waard is).

Als je uitsluitend MySQL gebruikt is MySQLi eigenlijk de beste driver, omdat PDO niet geschreven is voor MySQL, daarvoor is de PDO_MYSQL driver, en daar zit een aanzienlijke brok configuratie die je goed onder de knie moet hebben voor foutvrije operatie. De vraag is ook, wanneer je PDO gebruikt, of je deze abstractie ooit echt nodig hebt. Als je nooit van plan bent om te schakelen van database in een applicatie (ik heb hier eigenlijk nog nooit van gehoord in applicaties) dan kun je net zo goed MySQLi gebruiken omdat deze expliciet is geschreven en geoptimaliseerd voor gebruik van MySQL.

Deze wrapper dient uiteraard niet triviaal te zijn, simpelweg een soort van MyDB class bakken waarbij je vervolgens direct met een mysqli-object kunt werken is te kort door de bocht - dit stuk code moet echt werk uit handen nemen en daardoor een zekere meerwaarde creëren. Met dus als bijkomend voordeel dat je de omgang met je MySQL-database in afzondering van de rest van je code kunt behandelen.

Het belangrijkste hier is eigenlijk dat je hardcoding (zoveel mogelijk) voorkomt en niet in herhaling treedt met wat in wezen al eerder misging.