Van mijn stagebegeleider moet ik switchen van mysqli naar PDO omdat ze dat hier al gebruiken en hij niet alleen voor mijn projectje apart wat anders gaat gebruiken. Alleen heb ik geen flauw idee hoe dat moet. Misschien als ik een voorbeeld zie dat ik de rest wel zelf kan, dus hier heb ik database.php nog met mysqli. Hoe zou dit er uit moeten zien met PDO?
<?php
if(!defined('Include')){ //Prevent direct access
header("Location: http://www.voorbeeld.nl/");
}
else{
$db_host="localhost";
$db_name="databasenaam";
$username="root";
$password="";
$db_con=mysqli_connect($db_host,$username,$password,$db_name);
// Connection
mysqli_connect($db_host,$username,$password,$db_name);
// Check connection
if (mysqli_connect_errno())
{
echo "Failed to connect to MySQL: " . mysqli_connect_error();
}
}
?>
Van mijn stagebegeleider moet ik switchen van mysqli naar PDO omdat ze dat hier al gebruiken en hij niet alleen voor mijn projectje apart wat anders gaat gebruiken
Wait, what. Gebruiken ze dan iets anders dan MySQL in die toko? En wat is dan je motivatie om dat te gebruiken als het om een (standalone?) projectje gaat? "Omdat we dat hier al gebruiken" lijkt mij geen fantastische motivatie, tenzij je je aan stricte codeconventies moet houden maar volgens mij is dat hier niet aan de orde? Als zij niet kunnen motiveren waarom het PDO *moet* zijn en jij wel gegronde redenen hebt om mysqli te gebruiken - lekker zo laten.
Over de opzet van de code kun je natuurlijk twisten... :p
Het bovenstaande (de PDO variant) zal in principe wel werken denk ik, en het is misschien wel interessant om te zien of precies die oplossing geaccepteerd wordt. Dat zou namelijk nogal hilarisch zijn omdat ze je dan enerzijds een "correcte" werkwijze door de strot proberen te duwen, terwijl je anderzijds met root naar je database connect (wat volgens mij een redelijke doodzonde is) en je tevens geen character encoding selecteert bij het maken van een verbinding (wat op termijn voor allerlei vervelende problemen kan zorgen).
Volgens mij komt het ook steeds vaker voor dat mensen elkaar simpelweg na-papegaaien dat het PDO moet zijn, zonder dat ze nu eigenlijk weten waarom of dit uberhaupt kunnen motiveren...
EDIT het selecteren van een database driver/extensie is een ontwerpbeslissing en niet simpelweg een kwestie van syntactic sugar.
Thomas, heb je al eens gedacht aan dat stagiaires tijdelijk zijn? Mogelijk wil het bedrijf de source daarna in eigen beheer hebben, en zijn ze daar gewoon gewend om met PDO om te gaan. En verder is het voor de topicstarter ook vast en zeker een uitdaging om eens iets nieuws te leren ontdekken.
Volgens mij komt het ook steeds vaker voor dat mensen elkaar simpelweg na-papegaaien dat het PDO moet zijn, zonder dat ze nu eigenlijk weten waarom of dit uberhaupt kunnen motiveren...
Het komt ook veel voor dat PHP programmeurs hun eigen idee hebben van wat "goed" is, en alles wat niet aan hun idee voldoet verslijten als onzin.
In dit geval is het simpel; het bedrijf gebruikt PDO, dus doet de temp dat ook. Hij zal ook wel een coding standard moeten aanhouden en nog veel meer dingen die volstrekt normaal zijn in bedrijven waar meerdere programmeurs samenwerken.
Binnen bedrijven wordt vaak een coding standaard gehanteerd. Waarom zou iemand daarvan afwijken?
Ik kan me indenken dat een stagiaire daar dan ook aan moet voldoen. En voor een studieproject mag een bedrijf toch eisen stellen? Dat is gewoon realiteit in de IT-wereld.
Mogelijk wil het bedrijf de source daarna in eigen beheer hebben, en zijn ze daar gewoon gewend om met PDO om te gaan.
Afgaande op het bovenstaande codevoorbeeld lijkt dit een standalone script. Het lijkt mij als bedrijf geen goede strategie om op deze manier allerlei eilandjes te creëren.
gewend
Precies mijn punt.
Het komt ook veel voor dat PHP programmeurs hun eigen idee hebben van wat "goed" is, en alles wat niet aan hun idee voldoet verslijten als onzin.
Het maakt niet uit wat je doet, zolang je maar kunt motiveren waarom je iets doet. Waarom zou je PDO gebruiken? Sterker nog: why not go all in? Op het moment dat je PDO gaat gebruiken is dan het gebruiken van een database abstractielaag ook een verplichte vervolgstap? Ik bedoel, waarom introduceer je dit soort complexiteit als je er verder weinig tot niets van gebruikt? Een verkeerd gebruik van PDO is net zo funest als een verkeerd gebruik van een andere oplossing.
coding standaard
Je gaat mij niet vertellen dat je op deze manier een database-connectie opzet met alle credentials in hetzelfde script. Op het moment dat je coding standaarden gebruikt ben je meestal in grotere systemen of pakketten bezig. De bovenstaande code heeft geenszins deze uitstraling.
Los van dit alles, ik zeg helemaal niet dat dit of dat gebruikt moet worden, ik plaats enkel vraagtekens bij de aanpak waarbij per se van X gebruik gemaakt dient te worden. Moet je dit zomaar blind volgen? Nee. Zou je je af kunnen/mogen vragen waarom je ergens voor kiest? Of op zijn minst inzage van motivering kunnen krijgen? Daar kun je ook iets van leren. Zelfs als het antwoord is dat iemand er nooit echt over nagedacht heeft.
Toch fijn dat ik meteen weer van die prekerige antwoorden krijg op het moment dat ik iemand uitdaag om eens na te denken over wat je nu eigenlijk aan het doen bent.
@topicstarter
- verdiep je in de MySQL / andere specifieke driver van PDO, daar zit het venijn en de leercurve
- maak op zijn minst gebruik van een try-catch constructie anders kan het maken van een connectie (uiteindelijk) resulteren in een fatal error die mogelijk je connectie-parameters prijsgeeft
- stel bij het maken van een verbinding expliciet de correcte character encoding in zodat er geen ruimte voor eigen (en mogelijk verkeerde) interpretatie is
@ariën
Leuke bliksemafleider, alle pijlen op het oorspronkelijke probleem zodat je de confrontatie niet meer aan hoeft te gaan? Lekker makkelijk.
