[PHP] MySQL_ of MySQLi of PDO ?

[Verwijderd]

Ik ben bezig met een applicatie in PHP te schijven welke wat omvang aanneemt dus waar je keuzes gaat maken.

Opzich zou je kunnen zeggen. iets dergelijkes als dit had je eerder moeten bedenken voordat je eraan begon, dit is echter geen probleem aangezien ik de code aan het optimaliseren ben en dus toch alles naloop en verbeter.

Ik ben me er van bewust geworden dat er meer is dan alleen mysql_ in PHP om een database te benaderen. Zo is er MySQLi en PDO wat mysql_ moet vervangen.

Nu is mijn applicatie helemaal MySQL based dus ik zou prima over kunnen stappen op MySQLi... iets wat me beter ligt denk ik dan PDO aangezien deze syntax wat lastig op me over komt. MySQLi zou daarbij wat sneller moeten zijn dan mysql_, echter de verschillen zijn vrij miniem.

PDO heeft als voordeel dat je ieder database type kunt benaderen, echter je query-methode is toch altijd verschillend dus even je DB overpompen van MySQL naar PostgreSQL is er niet bij zoals het lijkt.

Dus PDO valt denk ik af, of er moet echt een hele goede reden zijn om dit te gebruiken.

MySQLi ligt me meer en aangezien ik toch zoveel mogelijk in MySQL wil doen lijkt het me dit een goede oplossing. MySQL_ is volgens de guru's wat dirty en je kunt er een aantal zaken niet mee welke je wel met MySQLi kunt doen.

Het is overigens wel zo dat PDO wat extra opties heeft tov MySQLi, de vraag is of dit echt noodzakelijk kwaad is om te hebben.

De vraag is dus... is PDO wel zo handig om te gaan gebruiken in plaats van MySQLi, of zijn er ook mensen welke zeggen... blijf lekker bij mysql_ als je dat ligt. Zover ik weet blijft MySQL_ gewoon in PHP6 beschikbaar.

[DataGhost]

Een groot voordeel van mysqli en PDO is dat je prepared statements kan gebruiken, wat met de mysql-module niet kan. Hierdoor heb je bijvoorbeeld geen gezeik meer met SQL injection en dergelijke.
Persoonlijk heb ik voor PDO gekozen nadat ik gefrustreerd met mysqli gestopt ben. Ik wilde namelijk een wrapper-klasse maken die het een en ander voor mij afhandelt maar vooral bij prepared statements is dat niet heel triviaal (iets met variabel aantal argumenten die je in een user-functie niet met dezelfde syntax/functiedefinitie door kan geven by reference). De uiteindelijke oplossing waar ik op uitkwam had vrijwel dezelfde syntax als het equivalent van PDO en toen vroeg ik mezelf af waar ik nou helemaal mee bezig was
Volgens mij kan je PDO sowieso een stuk makkelijker uitbreiden omdat het al een klasse is, een 'wrapper'-klasse maken is dan niet zo lastig meer. Het nadeel van PDO is dat je niet *alle* native mysql-meuk kan gebruiken, iets wat mysqli wel kan, maar ik heb het dan ook nog niet nodig gehad.

[ Voor 7% gewijzigd door DataGhost op 19-04-2009 15:56 ]

[Verwijderd]

DataGhost schreef op zondag 19 april 2009 @ 15:55:
Een groot voordeel van mysqli en PDO is dat je prepared statements kan gebruiken, wat met de mysql-module niet kan. Hierdoor heb je bijvoorbeeld geen gezeik meer met SQL injection en dergelijke.

Dat voordeel had ik ook gelezen, je moet het alleen nog wel goed toepassen begreep ik... het is niet maar "zo" veilig.

Persoonlijk heb ik voor PDO gekozen nadat ik gefrustreerd met mysqli gestopt ben. Ik wilde namelijk een wrapper-klasse maken die het een en ander voor mij afhandelt maar vooral bij prepared statements is dat niet heel triviaal (iets met variabel aantal argumenten die je in een user-functie niet met dezelfde syntax/functiedefinitie door kan geven by reference). De uiteindelijke oplossing waar ik op uitkwam had vrijwel dezelfde syntax als het equivalent van PDO en toen vroeg ik mezelf af waar ik nou helemaal mee bezig was

Bekend probleem, en dan heeft PDO hier zeker zijn voordelen in.

Volgens mij kan je PDO sowieso een stuk makkelijker uitbreiden omdat het al een klasse is, een 'wrapper'-klasse maken is dan niet zo lastig meer.

Dit is erg handig van PDO inderdaad, dat zijn wel de voordelen waarom je er voor zou kunnen kiezen zoals je eerder ook al aangaf.

Het nadeel van PDO is dat je niet *alle* native mysql-meuk kan gebruiken, iets wat mysqli wel kan, maar ik heb het dan ook nog niet nodig gehad.

Ja dat is een groot struikelblok vind ik... dus daarom twijfel ik zeker.

[Johnny]

Het grote voordeel van PDO is dat je als programmeur niet de functies van allerlei databases hoeft te leren, zelfs al werk je nu alleen met MySQL dan kan je in de toekomst makkelrijker iets maken met bijvoorbeeld SQLite of PostGreSQL, en zelfs ook delen van je code en queries hergebruiken. Ook zullen er in PHP 6 weer nieuwe MySQL functies zitten onder de naam mysqlng, en je kennis van mysql_ en mysqli_ functies weer achterhaald is.

[pedorus]

Johnny schreef op zondag 19 april 2009 @ 17:01:
Ook zullen er in PHP 6 weer nieuwe MySQL functies zitten onder de naam mysqlng, en je kennis van mysql_ en mysqli_ functies weer achterhaald is.

Gelukkig niet:

quote: http://dev.mysql.com/downloads/connector/php-mysqlnd/

Q: Is mysqlnd a new PHP extension?

No, the new MySQL driver for PHP is not a new PHP extension. The driver is a replacement for the MySQL Client Library on the internal C level of the PHP extensions ext/mysql, ext/mysqli and PDO_MYSQL.

You can continue to compile the any of the above mentioned extension with the MySQL Client Library like ever since. We will not remove this functionality. Alternatively you can compile the extensions with mysqlnd. We suggest that you try it, because mysqlnd is easier to compile and we found it to be faster than the MySQL Client Library.

[wackmaniac]

Ik ben zelf voor een project een tijdje terug eens aan de slag gegaan met PDO en dat bevalt me eigenlijk wel. Het is idd even net iets anders dan de Mysql(i)_ methodiek, maar om nou te zeggen dat het beter is; zover wil ik niet gaan.

De grootste reden voor mij om PDO eens te gaan proberen was de mogelijkheid om een resultset direct in je eigen objecten te kunnen gieten, omdat ik namelijk aan een persistencemanager aan het werken was:

PHP:

return $result->fetchAll( PDO::FETCH_CLASS , 'MyClass' );

[OnTracK]

Dat kan met mysql(i) ook, vanaf PHP5, met

mysql(i)_fetch_object(resource $result [, string $class_name [, array $params ]] )

[DJMaze]

Statements is leuk als je een query meer dan 1x per script aanroep gebruikt echter, als je queries maar 1x gebruikt is het geen meerwaarde.

PDO is niet mijn voorkeur omdat het erg gelimiteerd is.

Als je voor PDO kiest (of een andere manier om meerdere databases te ondersteunen) gebruik dan views, procedures en functions om "het query" probleem te omzeilen.

Functions zijn in mijn ogen handiger dan statements omdat ze "compiled" in de database staan en daarmee een stuk sneller zijn.
Lees eens: http://www.paragoncorpora...eDetail.aspx?ArticleID=28

Persoonlijk gebruik ik mijn eigen extended classes omdat die bijhouden hoelang queries er over doen (voor debugging) en voor het verwerken en gooien van extra exceptions.

[ Voor 5% gewijzigd door DJMaze op 20-04-2009 03:02 ]

[wackmaniac]

OnTracK schreef op zondag 19 april 2009 @ 21:28:
Dat kan met mysql(i) ook, vanaf PHP5, met

mysql(i)_fetch_object(resource $result [, string $class_name [, array $params ]] )

Hehe, wist ik helemaal niet. Weer wat geleerd. Wat ik wel weer fijn vind is dat PDO het direct naar een array van objecten kan fetchen (zie code voorbeeld), wat toch weer een twee / drie regels code scheelt

[Verwijderd]

DJMaze schreef op maandag 20 april 2009 @ 03:00:
Statements is leuk als je een query meer dan 1x per script aanroep gebruikt echter, als je queries maar 1x gebruikt is het geen meerwaarde.

PDO is niet mijn voorkeur omdat het erg gelimiteerd is.

Als je voor PDO kiest (of een andere manier om meerdere databases te ondersteunen) gebruik dan views, procedures en functions om "het query" probleem te omzeilen.

Functions zijn in mijn ogen handiger dan statements omdat ze "compiled" in de database staan en daarmee een stuk sneller zijn.
Lees eens: http://www.paragoncorpora...eDetail.aspx?ArticleID=28

Persoonlijk gebruik ik mijn eigen extended classes omdat die bijhouden hoelang queries er over doen (voor debugging) en voor het verwerken en gooien van extra exceptions.

Dus jij gebruikt nog steeds mysql_* ?

[Sh4wn]

Ik zou voor MySQLi gaan, als je niet van plan bent een ander DBMS te gebruiken. MySQLi ondersteunt ook prepared statements:
http://nl.php.net/manual/en/mysqli.prepare.php

MySQLi is ook meer geoptimaliseerd voor MySQL, en heeft een aantal extra mysql only functies.

[Cartman!]

Wat voor bepaalde functies heeft PDO niet die mysql(i)_ functies wel hebben dan bijvoorbeeld

Gebruik zelf Zend_Db_Adapter_Pdo_Mysql, een wrapper om PDO heen. Je kunt zover ik weet vrij snel wisselen tussen MSSQL, SQLITE, PostgreSQL, Oracle en IBM.

[Verwijderd]

Cartman! schreef op maandag 20 april 2009 @ 16:56:
Wat voor bepaalde functies heeft PDO niet die mysql(i)_ functies wel hebben dan bijvoorbeeld

Gebruik zelf Zend_Db_Adapter_Pdo_Mysql, een wrapper om PDO heen. Je kunt zover ik weet vrij snel wisselen tussen MSSQL, SQLITE, PostgreSQL, Oracle en IBM.

Maar de vraag is wat belangrijk is aan dat wisselen ? Je kunt toch ook gewoon de PgSQL module laden en die gebruiken ?

[Cartman!]

Ja, dat bedoel ik dus...simple as that.

Nog ff TS nagelezen en ik dacht gelezen te hebben dat ie dacht dat t met PDO juist niet kon maar dat had ie wel goed. Hij bedoelt alleen dat migeren zelf lastig zou zijn, maar dat staat toch los van wat je gebruikt in je script. Het mooie aan PDO (althans aan Zend_Db) is dat ik in principe geen queries meer schrijf.

[DJMaze]

Verwijderd schreef op maandag 20 april 2009 @ 09:56:
[...]


Dus jij gebruikt nog steeds mysql_* ?

Nee, ik bedoel SQL functions niet de php functions.
http://dev.mysql.com/doc/refman/5.1/en/create-function.html

Functions zijn net zoiets als procedures maar dan sneller!
http://www.paragoncorpora...eDetail.aspx?ArticleID=28

[ Voor 19% gewijzigd door DJMaze op 20-04-2009 17:52 ]

[Verwijderd]

Ik wil deze duscussie toch nog even aanzwenegelen aangezien ik toch veel mensen hoor welke nog met volle tevredenheid mysql_ gebruiken.

Het zou tevens zeer tegenstrijdig zijn dat mysql_ uit PHP zou verdwijnen bij versie > 6

Waarom deze comotie dan ?

[Kwastie]

Verwijderd schreef op dinsdag 05 mei 2009 @ 16:32:
Ik wil deze duscussie toch nog even aanzwenegelen aangezien ik toch veel mensen hoor welke nog met volle tevredenheid mysql_ gebruiken.

Het zou tevens zeer tegenstrijdig zijn dat mysql_ uit PHP zou verdwijnen bij versie > 6

Waarom deze comotie dan ?

Ik verwacht als ze de mysql_* functies verwijderen uit PHP (en moeten worden vervangen door PDO) de populariteit van PHP daalt. En dat willen ze vast niet bereiken.

Want veel applicaties die gebruik maken van mysql_* functies moeten dan aangepast worden, en daar heeft lang niet iedereen zin in/geld voor/etc.

Deze commotie komt voort uit een roadmap waarin ooit stond dat mysql_* functies zouden verdwijnen en vervangen moesten worden door PDO.

Zelf heb ik voor PDO gekozen omdat daar namelijk bind parameters kunt gebruiken en je kunt wijzigen van database. (bijv. PostgreSQL ipv MySQL)

[Cartman!]

Er zijn ook mensen die met volle tevredenheid register_globals *on* gebruiken, wat is je punt?

[Verwijderd]

Cartman! schreef op woensdag 06 mei 2009 @ 10:12:
Er zijn ook mensen die met volle tevredenheid register_globals *on* gebruiken, wat is je punt?

Dat register_globals on niet veilig is en daarom appels met peren vergelijken is ?

[Cartman!]

En jij vind mysql_ functies wel helemaal veilig? Zoek die discussie eens op over SQL injection in PRG.

[cariolive23]

Cartman! schreef op woensdag 06 mei 2009 @ 10:40:
En jij vind mysql_ functies wel helemaal veilig? Zoek die discussie eens op over SQL injection in PRG.

SQL injection is een keuze op zich, dat heeft niets te maken met de functie die een query naar de database stuurt. Zolang de database iedere willekeurige SQL-string zonder morren uitvoert, kan er sprake zijn van SQL injection. Dat is op database-niveau niet na te gaan, je hebt er voor gekozen om dat nergens te controleren.

1) Geef geen rechten op directe toegang tot tabellen en hun data
2) Gebruik view's en stored procedures
3) Zorg voor database rollen met de juiste rechten, dan kan iemand nooit iets uitvoeren wat hij/zij niet mag uitvoeren
4) Zorg er voor dat iedere user met de juiste rol met de database connect

Probleem opgelost! Gebruikers kunnen alleen die zaken uitvoeren die ze mogen uitvoeren. Ze kunnen hooguit via een omweg dezelfde zaken uitvoeren die ze toch al mochten uitvoeren. Men kan hooguit de eigen data verknallen, maar dat mag dan blijkbaar.

SQL injection is geen fout in de applicatie en/of database, het is een bewuste ontwerpkeuze. En dit heeft dus niets met een functie/methode/programmeertaal te maken.

[Verwijderd]

Uhm,. MySQLi heeft standaard ook last van Injection.... je moet het op de juiste manier gebruiken, netzoals mysql_ en dan heb je er geen last van...

Het is dus niet zo dat MySQLi dat bij voorbaat tegen gaat.

[Cartman!]

cariolive23: zo kun je alles wel zetten tegenover ontwerpkeuze. "ik gebruik register_globals on omdat ik daarna goed afvang wat wel en niet mag"

Ik zie geen enkel voordeel om mysql_ te gebruiken boven PDO en geen nadeel om PDO niet te gebruiken.

[cariolive23]

@Cartman!: Met register_globals on zet je de deur open voor alle toepassingen. Door een rol in de database aan te maken die alleen rechten krijgt voor datgene wat deze rol mag doen, gooi je automatisch de deur dicht voor alle andere mogelijkheden. Een open deur of een gesloten deur, dat maakt nogal verschil in veiligheid.

Vele programmeurs geven hun databaserol álle rechten en gaan hier vervolgens alles mee doen. (bij shared hosting heb je vaak ook geen keuze) Daarmee wordt het onmogelijk om op databaseniveau vast te kunnen stellen wie er iets uitspookt en of dat wel mag. Dat moet je dan zelf gaan programmeren en overal weer controleren. Je wordt daarmee afhankelijk van de kennis en kunde van een programmeur en de veiligheid van de script-/programmeertaal waar je mee werkt. Wanneer je een databaserol geen rechten geeft om X te doen, kan X nooit door deze rol worden uitgevoerd. Het maakt dan niets uit welke script- of programmeertaal je gebruikt, de data in de database is veilig.

mysql_ zou ik niet gebruiken, ik zou eerder voor mysqli_ of PDO kiezen. Mocht ik echt met MySQL moeten werken.

[Cartman!]

Hoe zie je dat dan praktisch voor je dat een user geen item mag toevoegen bijv. en een admin wel. Ga je dan applicatie-logica in je DB al afhandelen? Naar mijn idee is die er voor het opslaan van data namelijk.

[Verwijderd]

cariolive23 schreef op donderdag 07 mei 2009 @ 03:11:
mysql_ zou ik niet gebruiken, ik zou eerder voor mysqli_ of PDO kiezen. Mocht ik echt met MySQL moeten werken.

Je onderbouwt dit helaas niet.

Tevens.. Register Globals staat standaard uit... dat is een PHP ding en heeft verder weinig met the mysql extentie te maken binnen PHP.

[Kalentum]

in de PHP handleiding staat ook nog wat info hierover: http://nl3.php.net/manual/en/mysqli.overview.php

De mysql extensie wordt sowieso niet meer doorontwikkeld en ondersteunt geen prepared statements. Dus dat valt sowieso af.

Wil je 1 functieset voor verschillende databases? Dan is PDO een aanrader (of een framework, want die hebben vaak ook een databaseabstractielaag).

Wil je het onderste uit de kast qua performance of voldoen de functies van PDO niet? Dan mysqli.

[Verwijderd]

Jij zegt dus dat PDO ook trager is ?

Is die driver nooit geupdate dan ? Dit zou de bottleneck moeten zijn zegt men.

[Kalentum]

Verwijderd schreef op donderdag 07 mei 2009 @ 14:41:
Jij zegt dus dat PDO ook trager is ?

Geen idee eigenlijk. Elk extra laagje zorgt voor enige vertraging. Of het meetbaar is weet ik niet. Of het relevant is ook niet. Hangt van de specifieke situatie af. En van je overige code.

Ik denk dat je meer moet kijken waar je behoefte aan hebt qua functies.

[Verwijderd]

OK, ik ben begonnen een applicatie om te bouwen naar PDO.

Gelukkig kun je, als je al een classe gebruikte als ez_sql, dan is het vrij simpel en straight forward.

Ik vraag me overigens af of ik verdere functies direct toe zal passen. Het quote en dergelijke zal ik wel gebruiken... maar vreselijk OOP wacht ik nog even mee

[pedorus]

Verwijderd schreef op donderdag 07 mei 2009 @ 23:19:
OK, ik ben begonnen een applicatie om te bouwen naar PDO.

Prima keuze.

Gelukkig kun je, als je al een classe gebruikte als ez_sql, dan is het vrij simpel en straight forward.

ez_sql kun je weggooien: geen parameterized queries, errors die geoutput worden, enz... We zijn echt 7 jaar verder inmiddels...

Ik vraag me overigens af of ik verdere functies direct toe zal passen. Het quote en dergelijke zal ik wel gebruiken... maar vreselijk OOP wacht ik nog even mee

quote hoef je bijna nooit te gebruiken! Het gaat juist om de parameterized queries...

[Verwijderd]

pedorus schreef op vrijdag 08 mei 2009 @ 00:05:
[...]

Prima keuze.

Dacht ik

[...]

ez_sql kun je weggooien: geen parameterized queries, errors die geoutput worden, enz... We zijn echt 7 jaar verder inmiddels...

Je snapt mijn insteek wel denk ik. Meeste queries zijn op een PDO manier gedaan met ezsql en er schijnt zelfs een PDO versie van te zijn las ik ergens... toch niet meer nodig

[...]

quote hoef je bijna nooit te gebruiken! Het gaat juist om de parameterized queries...

Gaat mij er om dat ik eerst simpele select en insert en updates kan doen met mijn bestaande queries... Als ik dat omgezet heb ga ik verder kijken.

[Voutloos]

cariolive23 schreef op woensdag 06 mei 2009 @ 23:20:
Probleem opgelost! Gebruikers kunnen alleen die zaken uitvoeren die ze mogen uitvoeren. Ze kunnen hooguit via een omweg dezelfde zaken uitvoeren die ze toch al mochten uitvoeren. Men kan hooguit de eigen data verknallen, maar dat mag dan blijkbaar.

Nofi, maar dit is echt onzin. Rechten niet te ruim instellen is uiteraard in het algemeen een goed idee, maar het lost veel van de gevaren van sql injection niet op.

Zelfs met goed ingestelde rechten wil je niet dat queries naar willekeur aangepast kunnen worden dmv user input.

[pedorus]

Verwijderd schreef op vrijdag 08 mei 2009 @ 00:12:
Gaat mij er om dat ik eerst simpele select en insert en updates kan doen met mijn bestaande queries... Als ik dat omgezet heb ga ik verder kijken.

Het lijkt me beter om het in een keer goed te doen met prepared statements. Juist voor simpele selects en inserts heb je quote() echt niet nodig als je het goed doet. Daarnaast is het niet verboden om (tijdelijk) zowel PDO- als mysql_*-connecties naar je database te hebben, dus het is niet zo dat je gelijk alles om moet hebben gezet.

[Cartman!]

Zend_Db implementeert PDO op een fantastische manier imo. Schrijf vrijwel geen queries zelf meer en hoef me niet meer druk te maken om sql injection Componenten van Zend Framework kun je los gebruiken dus ik kan ieder het aanraden.

Verder eens met Voutloos ook. Zoals ik al liet doorschemeren vind dat cariolive23 er n beetje 'anders' over denkt.

[cariolive23]

Voutloos schreef op vrijdag 08 mei 2009 @ 09:12:Zelfs met goed ingestelde rechten wil je niet dat queries naar willekeur aangepast kunnen worden dmv user input.

Mee eens, een gebruiker heeft niks te zoeken in de SQL, maar met de juiste rechten wordt het onmogelijk om schade aan te richten of informatie op te halen die men niet mag inzien. De schadelijke effecten van SQL injection worden daarmee volledig de nek omgedraaid.

Hou ook in je achterhoofd dat 1 database vele applicaties van data kan voorzien. De ene applicatie kan in PHP zijn gebouwd, de andere in Java, .NET, of ik weet niet wat. Het is dan wel zo handig dat je dan de database op een centraal punt beveiligt, in de database zelf. Alle gebruikers en applicaties profiteren daar dan van. Het scheelt de DBA een hoop slapeloze nachten, hij/zij wordt er op afgerekend wanneer er iets fout gaat met de database.

Laat databases doen waar ze goed in zijn, het beheren en beschermen van data. Daar zijn ze voor gemaakt.

[Verwijderd]

Is het niet een beetje overdreven om een prepared te gebruiken als je gewoon een simpele query doet met een $_POST variabele ?

Lijkt mij wel namelijk.

Ik refereer hier even naar:
http://phpbuilder.com/manual/en/function.pdo-prepare.php

en vergelijk dat dan maar eens met de query()

[Voutloos]

cariolive23 schreef op vrijdag 08 mei 2009 @ 22:48:
Mee eens, een gebruiker heeft niks te zoeken in de SQL, maar met de juiste rechten wordt het onmogelijk om schade aan te richten of informatie op te halen die men niet mag inzien. De schadelijke effecten van SQL injection worden daarmee volledig de nek omgedraaid.

Twee woorden: Grote Bullshit. Je begrijpt duidelijk niet wat de effecten van SQL injection kunnen zijn.

Stel, jouw app moet op de users tabel select rechten hebben. Check? Stel, we stellen helemaal geen andere rechten in, dan kan er volgens jou weinig mis gaan. Maar ik heb zo'n vermoeden dat je dan mooi de mist in gaat met een 'SELECT * FROM users WHERE username = '".$_POST['username']."' AND password = '".$_POST['password']."'" query als inlog methode.

Je kan niet alles met rechten afvangen. Dat je db user bepaalde rechten nodig heeft voor bepaalde queries betekent nog niet dat alle mogelijke queries met diezelfde rechten onschadelijk zijn.

[cariolive23]

Stel, jouw app moet op de users tabel select rechten hebben.

Dat krijgt 'ie dus niet. Ik geef database rollen geen toegang tot tabellen, dat hebben ze niet nodig. Rechten op views, functions etc. zijn meer dan genoeg. Daarmee kan ik tot op recordniveau bepalen wat een bepaalde rol wel of niet mag zien. Je krijgt nooit en te nimmer toegang tot gevens waar je volgens jouw rol niet bij mag komen. Onmogelijk. Ook invoeren van data die je niet mag invoeren wordt onmogelijk. En mocht het tóch mogelijk zijn, dan kan iedere database die ik ken (DB2, Oracle, PostgreSQL, SQL Server, MySQL) zijn GRANT en REVOKE functionaliteit naar de schroothoop brengen, dan is dat blijkbaar zo lek als een mandje.

Databases spijker ik op databaseniveau dicht. Niets of niemand kan dan iets uitspoken wat ze niet mogen doen. Even een één-tweetje tussen DBA en programmeur en het zaakje is voor eens en voor altijd veilig dichtgespijkerd. En dat voor alle applicaties die van de database gebruik maken. Scheelt weer in beheer en onderhoud.

Ik mag trouwens hopen dat jij nooit wachtwoorden (of hashes daarvan) ophaalt uit een database, die heb je nooit nodig buiten de database, alleen voor de vergelijking. Deze data geef je dan ook nooit retour naar een applicatie. Dat is met een view of function eenvoudig af te vangen.

Edit: Deze aanpak heeft ook als voordeel dat je het datamodel kunt veranderen/optimaliseren zonder dat je de applicaties hoeft aan te passen. Zolang je geen andere in- en output verwacht/levert, is er niets aan de hand. Een ander voordeel is dat je de runtime-configuratie van de database kunt afstemmen op de specifieke databaserol/view/function. Dit kan flinke performance winst opleveren voor alle gebruikers en applicaties.

[ Voor 13% gewijzigd door cariolive23 op 08-05-2009 23:52 . Reden: Bonus toegevoegd bij het gebruik van views en functions. ]

[Verwijderd]

Ontopic please ???

[pedorus]

Verwijderd schreef op vrijdag 08 mei 2009 @ 22:49:
Is het niet een beetje overdreven om een prepared te gebruiken als je gewoon een simpele query doet met een $_POST variabele ?

Lijkt mij wel namelijk.

Ik refereer hier even naar:
http://phpbuilder.com/manual/en/function.pdo-prepare.php

en vergelijk dat dan maar eens met de query()

Hoezo? Zoveel langer is dat echt niet, zeker als je de ?'s gebruikt. En het is duidelijker om onderscheid te hebben tussen de query en de input. Theoretisch kan het ook nog eens sneller zijn. En het belangrijkste is natuurlijk dat je niet per ongeluk quote() of de aanhalingstekens kan vergeten.

Als het je eigenlijk om het aantal karakters gaat, zou ik je aanraden om mysql_query_safe te integreren in ez_sql. Kan heel makkelijk, en minder karakters zal het echt niet zomaar worden... Lees anders even dat draadje door.

@cariolive23: En hoe zorg je ervoor dat je maximaal 20 zoekresultaten op een pagina hebt en je geen denial of service attack krijgt door middel van foute queries?...

[Verwijderd]

pedorus schreef op zaterdag 09 mei 2009 @ 00:37:
[...]

Hoezo? Zoveel langer is dat echt niet, zeker als je de ?'s gebruikt. En het is duidelijker om onderscheid te hebben tussen de query en de input. Theoretisch kan het ook nog eens sneller zijn. En het belangrijkste is natuurlijk dat je niet per ongeluk quote() of de aanhalingstekens kan vergeten.

Het lijkt in den beginselen wat omslachtig namelijk om dit zo te doen.

Als het je eigenlijk om het aantal karakters gaat, zou ik je aanraden om mysql_query_safe te integreren in ez_sql. Kan heel makkelijk, en minder karakters zal het echt niet zomaar worden... Lees anders even dat draadje door.

Wat moet ik met ez_qsl als ik overstap op PDO ???

[Voutloos]

cariolive23 schreef op vrijdag 08 mei 2009 @ 23:39:
Ik mag trouwens hopen dat jij nooit wachtwoorden (of hashes daarvan) ophaalt uit een database, die heb je nooit nodig buiten de database, alleen voor de vergelijking. Deze data geef je dan ook nooit retour naar een applicatie. Dat is met een view of function eenvoudig af te vangen.

Dude, dat is het punt niet. Je hebt 'een query' nodig voor het inloggen van je gebruikers. Hoe je de rechten ook instelt, alle gebruikers moeten kunnen inloggen, maar een aanvaller moet niet kunnen inloggen met "Admin' OR '1" als username. No way dat je dit soort aanvallen in de praktijk met enkel jouw aanpak altijd af vangt.

End of story. Als je er nog steeds in gelooft prima, maar dan hoop ik iig nooit met jouw apps geconfronteerd te worden. Verder ga ik niet meer op geblaat in, dus bij deze einde offtopic.

[NMe]

Modbreak:

Laten we die offtopic (en onvriendelijke!) discussie maar hier stoppen.

[Verwijderd]

Hoe staat men tegenover DBD::mysql ?

Dus Perl gebruiken om tegen verschillende DB's te kunnen praten ? De DBD laag doet de juist query richting het DB type dat je gebruikt....

[Cartman!]

En waarom zou je dat dan weer willen?

[Verwijderd]

Cartman! schreef op vrijdag 22 mei 2009 @ 09:09:
En waarom zou je dat dan weer willen?

Omdat dat er best degelijk en mooi uit ziet en erg flexibel tussen verschillende DB-soorten werkt.

Probleem is alleen dat Perl naar mijn idee toch echt langzaam kan zijn....

[Manuel]

Ik gebruik nu ook al een hele poos PDO, het was voor mij ook de gok om eraan te beginnen. Iedereen wil het natuurlijk zo snel mogelijk hebben wat begrijpbaar is maar heb nooit eens een degelijke bechmark voorbij zien komen wat betreft MySQL / MySQLi / PDO.

Daarom heb ik zelf ook de gok maar genomen om het eens te testen. Ik vind PDO veel makkelijker werken dan MySQL(i), hier heb ik ook zo mijn redenen voor. Voornamelijk was dat ik eerst alles moest gaan escapen voordat een query pas "veilig" was.

MySQL(i) is een hel als je het mij vraagt, kwam heel veel fouten van mezelf tegen om een goede classe voor MySQL(i) te maken (zodat ik makkelijker kan werken). Als je het mij vraagt is het te drastisch veranderd ten opzichte van MySQL functies opzicht (mysql_query, mysql_fetch_assoc) en zo zijn ze op te noemen.

Geef mij dus maar PDO, veel makkelijker in onderhoud als ik eens van database ga wisselen, dan maar 1 regel aanpassen (misschien nog wat SQL maar dat is alles).

offtopic:
Heb al een hele poos zitten te Google'n maar je blijft maar uitkomen op hele oude topics, daarmee bedoel ik vanaf 2007 en lager. Dus als iemand eens een klein benchmark overzicht heeft zou het fijn zijn.

[Cartman!]

Verwijderd schreef op vrijdag 22 mei 2009 @ 19:33:
[...]
Probleem is alleen dat Perl naar mijn idee toch echt langzaam kan zijn....

Maar hoe wil je dat vanuit PHP gaan aanspreken? Lijkt me enorm onhandig...

[doeternietoe]

Manueltje22 schreef op vrijdag 22 mei 2009 @ 19:58:
Daarom heb ik zelf ook de gok maar genomen om het eens te testen. Ik vind PDO veel makkelijker werken dan MySQL(i), hier heb ik ook zo mijn redenen voor. Voornamelijk was dat ik eerst alles moest gaan escapen voordat een query pas "veilig" was.

Ik gebruik momenteel vooral prepared statements in mysqli en dan heb je ook het probleem van escapen niet. Ik overweeg echter om eens PDO te gaan gebruiken, met name omdat je daar gebruik kunt maken van named parameters. Ik vraag me eigenlijk af of het veel zin heeft om de Zend implementatie van PDO te gebruiken in plaats van de standaardextensie.

[Manuel]

doeternietoe schreef op zaterdag 23 mei 2009 @ 12:53:
[...]

Ik gebruik momenteel vooral prepared statements in mysqli en dan heb je ook het probleem van escapen niet. Ik overweeg echter om eens PDO te gaan gebruiken, met name omdat je daar gebruik kunt maken van named parameters. Ik vraag me eigenlijk af of het veel zin heeft om de Zend implementatie van PDO te gebruiken in plaats van de standaardextensie.

Dankje voor je antwoord! Het nadeel vind ik alleen dat ik dan bijna elke query als prepared statement moet uitvoeren, dat is dus voor mij het nadeel. Ik specificeer nu ook per PHP wat voor type het is, (int) en ga maar door.

Het handige aan PDO (wat ik vind), is dat je "resultsets" aan variabelen kan koppelen, ik gebruik dat nu namelijk veel, zoiets was volgens mij (nog) niet mogelijk met MySQL(i)?

[Luqq]

Vroeger gebruikte ik altijd mysql, later ben ik overgestapt op mysqli voor de prepared statements, maar ik gebruik nu PDO, eigenlijk alleen voor de fetchAll functie, aangezien ik smarty gebruikt

[Verwijderd]

doeternietoe schreef op zaterdag 23 mei 2009 @ 12:53:
[...]
vraag me eigenlijk af of het veel zin heeft om de Zend implementatie van PDO te gebruiken in plaats van de standaardextensie.

Dit is dus ook een vraag welke ik mij stel.... zeker als je alleen het SQL gedeelte van Zend gebruikt.

[Manuel]

Waarom zou je een apart framework gebruiken om alleen het SQL gedeelte ervan te gebruiken is de vraag dan, misschien hier een leuk argument hiervoor?

[Verwijderd]

Manueltje22 schreef op zaterdag 23 mei 2009 @ 14:47:
Waarom zou je een apart framework gebruiken om alleen het SQL gedeelte ervan te gebruiken is de vraag dan, misschien hier een leuk argument hiervoor?

Omdat de methode van queries schrijven opzich wel handig is.

Echter, bij een CMS of wat dan ook vorm je uiteindelijk je eigen framework meestal zonder dat je het merkt.

[doeternietoe]

Manueltje22 schreef op zaterdag 23 mei 2009 @ 14:47:
Waarom zou je een apart framework gebruiken om alleen het SQL gedeelte ervan te gebruiken is de vraag dan, misschien hier een leuk argument hiervoor?

Omdat Zend ertoe uitnodigt om dat te doen. De verschillende onderdelen zijn heel goed los van elkaar te gebruiken. Bovendien zijn er wel meer onderdelen in Zend die erg bruikbaar zijn, zoals de mail-functionaliteit.

[Manuel]

@doeternietoe dan moet je wel eerst weer het framework "leren gebruiken" en toepassen, ik programmeer liever iets zelf zodat ik daar 100% controle over heb. Dan weet ik sneller waar de fout zit omdat ik het zelf heb geprogrammeerd.

Ik twijfel niet aan een framework wat betreft functionaliteiten maar eerder aan dat ik het verspilde schijfruimte vindt omdat ik de meeste onderdelen dan toch niet ga gebruiken.

@RutgerM Voordat ik een framework uit mezelf neem zie ik liever performance-winst, dat is dan één van de redenen om een framework te nemen. Als mijn applicatie er zo sloom van wordt als het maar kan zeg ik eerder nee dan ja.

[Verwijderd]

Manueltje22 schreef op zaterdag 23 mei 2009 @ 16:10:
@RutgerM Voordat ik een framework uit mezelf neem zie ik liever performance-winst, dat is dan één van de redenen om een framework te nemen. Als mijn applicatie er zo sloom van wordt als het maar kan zeg ik eerder nee dan ja.

Mijn inziens spreek je jezelf dus tegen.... dat snap ik niet helemaal...

[Manuel]

Nu je het zo zegt inderdaad, ik bedoelde dus ook dat als ik eens ga besluiten één te nemen dan moet het veel voordelen hebben, zo ook dat ik performance winst wil zien. Hopelijk is het nu wat duidelijker.

[Cartman!]

RutgerM, hoe kom je er nu bij om Perl te gebruiken vanuit PHP? Ik ben daar nog steeds benieuwd naar...

[Verwijderd]

Cartman! schreef op zaterdag 23 mei 2009 @ 22:36:
RutgerM, hoe kom je er nu bij om Perl te gebruiken vanuit PHP? Ik ben daar nog steeds benieuwd naar...

DBD::MySQL is toch een perl laag tussen DB en PHP ? OF zit ik er nu naast dan ? Zal het nog eens op een normaler tijdstip nalezen.

Zover ik begreep kan Perl interacten tussen PHP en DB's zoals PDO dit ook kan.

[Cartman!]

Ik zou het nog eens nalezen dan

[Verwijderd]

Cartman! schreef op zondag 24 mei 2009 @ 12:20:
Ik zou het nog eens nalezen dan

Ja zal ik doen Hoewel ik toch voor native PDO ga... aangezien dit flexibeler is in je ontwikkeling