kan dit slimmer?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Software IT Quality Ontwikkelaar Audits 3.200 - 4.

Functieomschrijving Software IT Quality Ontwikkelaar Audits 3.200 - 4.500 Quality Manager Voor de vacature als Software IT Quality Ontwikkelaar Eindhoven Audits ga je het volgende doen: Beschrijving: Relevante activiteiten van een Quality Officer zijn: • Onderhouden en verbeteren van het kwaliteitssysteem • Het monteren van managementrapporten. • Voorbereiding en coördinatie van externe audits. • Uitvoeren en plannen van interne audits (nalevingscontrole). • Registreren en behandelen van problemen en verbetervoorstellen. • Ondersteuning van de verbetering van de diverse SW-ontwikkeling. Als Quality Officer heb je een belangrijke verantwoordelijkheid binnen ons bedrijf die het uitgevoerde werk van verschillende teams adviseert, ondersteunt en bewaakt.

Bekijk vacature »

Senior PHP developer verzekeringenbranche

Organisatie Een van Nederlands grootste verzekeringsmaatschappijen is opzoek naar een goede PHP developer. De organisatie is zo’n 220 man groot en heeft een development team van 15 developers. De IT afdeling speelt een belangrijke rol binnen de organisatie. De klanten regelen steeds meer online en veel is een geautomatiseerd proces. Deze grootschalige verzekering is gespecialiseerd in de auto, reis, aansprakelijkheid, inboedel, zorg, studentenzorg, woonhuis pechhulp, rechtsbijstand en annuleringsverzekeringen. Met bijna 300.000 klanten behoren zij tot de absolute top! Functie Als senior PHP developer bedenk je niet alleen nieuwe functionaliteiten, je gaat ze ook daadwerkelijk ontwikkelen. Je perfectioneert de technologie die

Bekijk vacature »

Frits van Leeuwen

Frits van Leeuwen

16/12/2018 23:40:19
Quote Anchor link
Hallo allemaal,

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)
PHP script in nieuw venster Selecteer het PHP script
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
 
PHP hulp

PHP hulp

16/01/2019 03:51:11
 
- Ariën -
Beheerder

- Ariën -

16/12/2018 23:42:35
Quote Anchor link
Ik heb te weinig code om dit te beoordelen, maar hoe ziet je database-structuur eruit?
 
Thomas van den Heuvel

Thomas van den Heuvel

17/12/2018 02:43:44
Quote Anchor link
tl;dr: kan dit slimmer? ja, gebruik iets anders

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
 
Frits van Leeuwen

Frits van Leeuwen

17/12/2018 08:55:36
Quote Anchor link
Heel er bedankt voor de reactie. Ooit gebruikte ik MYSQL en kreeg te horen dat die er uit ging. Ik ging wat speuren en las dat ik het beste kon overstappen op PDO en prepare gebruiken. Tot ik weer vast liep. Toen werd mij wijsgemaakt dat ik beter MYSQLI zou gebruiken. Ik heb toen alle PDO er weer uit gesloopt en omgezet in MYSQLi

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.
 
Ozzie PHP

Ozzie PHP

17/12/2018 10:59:35
Quote Anchor link
Frits, niet om vervelend te doen, maar als je een goede programmeur wilt worden/zijn dan zul je je keuzes moeten onderbouwen en ZELF moeten weten waarom je (wel of niet) voor een bepaalde oplossing kiest. Je geeft zelf nu al aan dat je ooit MySQL gebruikte ... dat je vervolgens van horen zeggen had dat je beter PDO kunt gebruiken ... dat lukte je niet ... toen werd jou wijsgemaakt dat je beter MySQLi kon gebruiken, waarna je maar weer bent gestopt met PDO. Zie je een patroon misschien ... ? ;)

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.
 
Frits van Leeuwen

Frits van Leeuwen

17/12/2018 16:07:42
Quote Anchor link
Ozzie,

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

17/12/2018 17:00:01
Quote Anchor link
Ik ben het met @Ozzie eens in die zin dat het niet belangrijk is wat je gebruikt, als je maar voor jezelf kunt onderbouwen waarom je een bepaalde werkwijze hanteert. En dan liefst ook voor redenen die ook echt hout snijden :).

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
 
Rob Doemaarwat

Rob Doemaarwat

17/12/2018 20:44:53
Quote Anchor link
Toch nog even on-topic:
- call_user_func_array
- Argument unpacking
 
Thomas van den Heuvel

Thomas van den Heuvel

17/12/2018 22:29:04
Quote Anchor link
@Rob, zoiets stond in de user comments, dit had ik een vorige reactie aangehaald :). Misschien had ik dit wat meer moeten benadrukken.

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
 
Frits van Leeuwen

Frits van Leeuwen

18/12/2018 00:23:18
Quote Anchor link
Wouw... wat een lang en mooi antwoord.
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.
 
Ozzie PHP

Ozzie PHP

18/12/2018 00:34:29
 
Thomas van den Heuvel

Thomas van den Heuvel

18/12/2018 00:59:36
Quote Anchor link

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.
 
Ozzie PHP

Ozzie PHP

18/12/2018 01:24:05
Quote Anchor link
@Thomas, is gewoon bedoeld als wat leesvoer. Niet om wat wel of niet juist is. Juist door e.e.a. te lezen kan iemand zich zelf een beeld vormen. Daar leer je van.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.