kan dit slimmer?
Ik ben al een tijdje op zoek of dat ik dit slimmer kan programmeren.
Ik heb een werkende regel, maar om 3 items uit een array in 1 opdracht zo neer te zetten... Dit moet slimmer kunnen lijkt me.
Code (php)
1
$stmt->bind_param($bind_param_type_result, $bind_param_value_array[1], $bind_param_value_array[2], $bind_param_value_array[3]);
Als die slimmere weg er is, dan heb ik daar soms meer items staan, want de eerste variabele wordt goed opgebouwd. Ook mij meer items.
Alvast bedankt,
Frits van Leeuwen
Ik ga ervan uit dat je MySQLi gebruikt, dus concreet mysqli_bind_param()?
Loop je in het gebruik hiermee vast, of wat is precies het probleem? Je vindt het omslachtig? Dat komt omdat prepared statements in MySQLi omslachtig zijn.
Zoals je in de manual kunt zien zijn de te binden parameters call by reference. Dit houdt in dat er speciale omstandigheden zijn met betrekking tot de werking. Heb je de user comments ook gelezen?
Daarnaast, wat probeer je precies te bereiken? Ben je iets generieks aan het maken zodat je niet zoveel hoeft te typen? Ben je uberhaupt meerdere dezelfde queries uit aan het voeren met verschillende waarden in een loop ofzo? Vraag jezelf af waarom je in eerste instantie prepared statements gebruikt? Dit is in mysqli namelijk nogal onhandig in het gebruik met veel (code-)overhead. Je moet je ook realiseren dat elke query die je prepared een query is die je de database in schiet. Een execute is een tweede query. Dus als je een sjabloon (de query die je prepared) doorgaans maar één keer gebruikt dan is dat nogal zonde. Ook is het lastig om queries te debuggen want je kunt nooit de query die daadwerkelijk is uitgevoerd bekijken, tenzij je je queries logt en in je in deze query-logs gaat graven... Als iemand wel weet hoe je een "preview" van een concrete query kunt oproepen hoor ik dit graag.
Er zullen vast "slimme" aanpakken zijn waarmee je dit generiek kunt maken, maar wellicht is het beter om ofwel:
- over te stappen naar PDO als je zo verzot bent op prepared statements (Joost mag weten waarom, heeft iemand je wijs gemaakt dat dit "het beste" is?)
- geen prepared statements te gebruikein in MySQLi, maar je te bedienen van een ander stramien om queries veilig te maken
Prepared statements in MySQLi zijn gewoon veelste omslachtig en onhandig in het gebruik naar mijn mening.
Waarom gebruik je deze precies? Want als je hier geen motivatie voor hebt zou ik gewoon zonder meer naar een andere werkwijze overstappen...
Gewijzigd op 17/12/2018 02:44:08 door Thomas van den Heuvel
Maar nu begrijp ik het juist andersom. Dat het sneller is als ik geen prepare gebruik. Als ik het prepare weg werk, zal het me wel lukken. Ik denk dat het een hoop code scheelt.
Ik wil absoluut niet zeiken, maar weet WAAROM je iets doet. Iets niet doen omdat het 'lastig' is, is wat mij betreft geen goede reden. Er zijn namelijk ook goede redenen om wél prepared statements te gebruiken. Omdat Thomas nu iets zegt, besluit jij zomaar (wederom) iets te gaan doen. Zorg eerst dat je weet WAAROM je iets wil doen, en ga dan pas daadwerkelijk aan de slag.
Dat is hoe ik erover denk. Ik wil je ervoor behoeden dat je straks weer tig keer alles aan het omgooien moet.
Ik heb het in grote lijnen geschetst. Wat ik zo al meemaakte. Het is niet dat ik het zomaar op geef.
Toen ik met MySQL niet verder kwam en een oplossing zocht, kwam ik een verklaring tegen waarin aangegeven werd dat MYSQL vanaf een bepaalde versie ging verdwijnen en daar stond ook bij dat je beter voor PDO kon kiezen dan MySQLi. Ik leerde werken met PDO en daar leerde ik prepare gebruiken. Dit ging me best goed af, maar liep toch ergens vast.
Wat ik tot dan toe had gemaakt kon ook in MySQLi en ook dat wat ik gevraagd had.
Alles was voor mij heel duidelijk dat ik die keuze moest maken. Ik zal nu naar mijn code gaan kijken of dat ik prepare wel moet gebruiken, of dat het beter is om alles direct in de query te zetten.
Is er ergens een overzicht waar het een en ander naast el kaar wordt vergeleken? Dek hierbij aan verschillende opdrachten, werkmethode en snelheden.
Er waren (en zijn) waarschijnlijk nog steeds een heleboel artikelen op het internet te vinden die het PDO-evangelie proberen uit te dragen, maar zich daarbij bedienen van argumenten die kant noch wal raken. Ook moet je de historie en werking van al deze varianten enigszins kennen en begrijpen om hierbij een weloverwogen keuze te maken. De oorspronkelijke MySQL-driver (concreet, alle mysql_-functies) zijn eigenlijk al 10+ jaar verouderd en zijn in PHP versie 7 definitief verwijderd. Deze heeft dus ondertussen het speelveld permanent verlaten. Al heel lang bestond er mysqli als opvolger en parallel hieraan was er ook PDO. Als je dus van een MySQL-database gebruik wilt maken heb je dus in principe twee smaken: mysqli of PDO.
Bij het maken van een keuze tussen deze twee varianten moet je ook argumenten voor het een of het ander hebben. Zo is mysqli specifiek geschreven en geoptimaliseerd voor het gebruik van een MySQL-database. PDO niet. Sterker nog, PDO "zelf" biedt geen enkele ondersteuning aan een specifieke database, dit doen de PDO-drivers, waaronder de PDO_MYSQL driver.
PDO zelf (een handjevol classes) standaardiseert alleen maar de communicatie met de database (PDO is dus in feite een Data Access Abstraction Layer of DAAL). Hetgene wat je communiceert is echter nog steeds database-specifiek, PDO biedt zelf geen volledige abstractie (via een Database Abstractie Laag) aan, hier zou je aanvullende libraries voor moeten gebruiken.
Het argument wat vaak werd (en misschien nog steeds wordt?) gebruikt dat "PDO meerdere databases ondersteunt (en mysqli maar één)" is dus in zekere zin wel waar, maar dat dit dan dus beter zou zijn is volstrekte onzin. In dat opzicht schiet PDO zelf ook tekort, in die zin dat geen "volledige abstractie" biedt. En zelfs dan zou je je af kunnen vragen wat voor doel dat dient, want geen enkele applicatie (die ik ken) schakelt tijdens de levensloop vrij tussen verschillende database-typen. Dus je hebt tig abstractielagen / volledige abstractie, cool, maar wat doe je er verder mee?
En dan de (misplaatste) uitstraling die PDO heeft (of wordt gepropageerd) dat dit simpel zou zijn. Sure, PDO zelf (het eerdergenoemde handjevol classes) is simpel. Maar de volledige leercurve zit ook niet daar maar in de staart, in de eerdergenoemde drivers. Omdat PDO niet geoptimaliseerd is voor een specifieke database is deze op voorhand dus ook niet speciaal geschikt voor MySQL. Je zult dus MySQL-driver-speficieke zaken moeten configureren en dat vereist toch wel enige kennis van (niet enkel MySQL-)zaken. Je moet echt begrijpen wat alles doet als je met PDO begint. Zo zijn er een heleboel PDO::ATTR_- en PDO::MYSQL_ATTR_-attributen die je in kunt stellen die alle van directe invloed zijn op de werking van de communicatie met je database (en niet alleen die van MySQL). Bij gebruikmaking van PDO moet je dus in zekere zin meer weten van MySQL dan wanneer je van MySQLi gebruikt.
Tot slot de simpele vraag: als ik dan toch alleen maar van MySQL gebruik maak, waarom maak ik dan geen gebruik van een driver die specifiek is geschreven en is geoptimaliseerd voor het gebruik van dat type database?
En als je dan hebt gekozen voor mysqli (of PDO), dan ben je nog niet klaar, want dan zul je je nog steeds moeten verdiepen in de werking van de driver zelf, en wellicht ook in de "Client API" - dit is de MySQL-client die de webserver draait om te communiceren met de MySQL-server.
En dan ben je eigenlijk pas klaar om een MySQL-database te gaan gebruiken via PHP, zodra je een beetje een beeld hebt van hoe alle puzzelstukjes in elkaar vallen. Maar het lijkt erop dat iedereen tegenwoordig op hetzelfde moment begint met zowel PHP als MySQL :p.
Over de snelheid: zowel mysql, mysqli als PDO waren volgens mij alle even snel. In de techniek zit de bottleneck in ieder geval niet. Tenzij je hele vreemde dingen doet die meestal te herleiden is tot brakke code, brakke queries, een brakke database-structuur, of een combinatie hiervan.
Ik denk dat waar je vooral naar moet kijken is wat fijn werkt. Voor mij houdt dat in dat ik mij niet het leplazerus typ en ook dat alles kort en bondig is. Ik meen mij te herinneren dat iemand zei dat het hun niet zoveel uitmaakte dat er elke keer (mysqli_)real_escape_string() werd uitgeschreven, omdat zijn code-editor toch code completion had. Ik heb gewoon liever dat dit is ingekort tot simpelweg ($db->)escape(). Een bijkomend voordeel hiervan is ook dat je database-specifieke instructies niet hard codeert in je code.
Een ander ding is debugging. Prepared statements staan je hierbij meestal in de weg. Je kunt moeilijk zien hoe de uiteindelijke query luidt die aan de database wordt gevoerd. Als je dan enkel de melding terugkrijgt dat er iets foutging dan heb je geen concrete query die je kunt debuggen, tenzij je in logs gaat graven. Plus het idee dat je je query-parameters onderwerpt aan type-checks tijdens de uitvoering is wellicht ook een beetje vreemd. Je zou eigenlijk alle data moeten valideren nog voordat je uberhaupt een poging onderneemt om een query uit te voeren.
Ah well, doe wat je wilt, zolang je maar kunt uitleggen waarom je doet wat je doet.
Gewijzigd op 17/12/2018 17:00:31 door Thomas van den Heuvel
EDIT: @topicstarter lees anders dit eens door (interne link). Bevat ook een DAAL voor MySQLi.
Gewijzigd op 17/12/2018 22:43:19 door Thomas van den Heuvel
Ik begrijp nu dat PDO het liefst alleen gebruikt wordt als je andere dan MYSQL databases gebruikt. Ik gebruik voor alsnog alleen MYSQL databases.
Dus ik gebruik MySQLi.
Prepare is een keuze om de boel overzichtelijk te houden of voor het gebruik van formules waar wisselende variabenen gebruik worden op de zelfde plek. En aangezien ik dat ook niet doe kan ik er beter voor kiezen om die niet te gebruiken.
Heel erg bedankt voor de uitleg. Ik heb weer veel geleerd. En wat ik wilde bouwen is me nu ook gelukt.
https://code.tutsplus.com/tutorials/pdo-vs-mysqli-which-should-you-use--net-24059
https://websitebeaver.com/php-pdo-vs-mysqli
Ozzie PHP op 18/12/2018 00:34:29:
Gedateerd, bevat valse/verkeerde argumenten en is biased ten faveure van PDO.
Ozzie PHP op 18/12/2018 00:34:29:
Is al wat objectiever die meer functionaliteit vergelijkt, maar hier zie je al meteen dat je het e.e.a. van PDO-properties en MySQL-specifieke instellingen moet weten om er goed mee te kunnen werken.
Ook is het handig om te weten dat PDO normaal prepared statements emuleert. Maar die worden hier uitgezet via ATTR_EMULATE_PREPARES en dit kan alleen omdat MySQL native prepared statements ondersteunt.
Vind het vreemd dat in dit artikel PDO de simpelere variant wordt genoemd eigenlijk. En begrijp nog steeds niet dat net wordt gedaan alsof prepared statements (in MySQLi) "the only way" is.