|
| MySQL og Prepared Statement Fra : Thomas Rokamp |
Dato : 10-12-03 16:36 |
|
Halløj
Jeg roder lidt med PHP og er stødt på funktioner til almindelige statements
og prepared statements.
Hvad er fordlee/ulemper ved dem hver især?
Hvornår bør jeg bruge det ene frem for det andet og modsat?
Jeg er kalr over, at prepared statements er til performance forbedring ved
visse kald, men hvor bliver de forberedte kald gemt? er det i PHP (serveren)
eller i databasen (connection)?
Håber ikke det var alt for forvirrende...
Mvh.
Thomas Rokamp
| |
Peter Lykkegaard (10-12-2003)
| Kommentar Fra : Peter Lykkegaard |
Dato : 10-12-03 23:47 |
|
Thomas Rokamp wrote:
>
> Jeg roder lidt med PHP og er stødt på funktioner til almindelige
> statements og prepared statements.
> Hvad er fordlee/ulemper ved dem hver især?
Laver du det samme kald flere gange med forskellige parametre så rykker det
> Jeg er kalr over, at prepared statements er til performance
> forbedring ved visse kald, men hvor bliver de forberedte kald gemt?
> er det i PHP (serveren) eller i databasen (connection)?
>
Databasen
Har du mulighed for at monitorere på din mySQL ting?
Så vil du kunne se hvad der sker
- Peter
- Peter
| |
Thomas Rokamp (11-12-2003)
| Kommentar Fra : Thomas Rokamp |
Dato : 11-12-03 00:08 |
|
> > Jeg roder lidt med PHP og er stødt på funktioner til almindelige
> > statements og prepared statements.
> > Hvad er fordlee/ulemper ved dem hver især?
>
> Laver du det samme kald flere gange med forskellige parametre så rykker
det
Ja, men ikke umiddelbart efter hinanden.
Jeg har de enkelte kald gemt væk i funktioner, der hver laver en ny prepared
statement. Men der er måske ingen idé med dem, hvis hvert prepared statement
kun udføres én gang pr. kald til funktionen?
> > Jeg er kalr over, at prepared statements er til performance
> > forbedring ved visse kald, men hvor bliver de forberedte kald gemt?
> > er det i PHP (serveren) eller i databasen (connection)?
> >
> Databasen
> Har du mulighed for at monitorere på din mySQL ting?
> Så vil du kunne se hvad der sker
Ikke så vidt jeg ved... det er på en udenbys host. Jeg har ssh adgang, så
hvis det kan klares over den vej kan jeg muligvis godt...
/Thomas
| |
Ole Nielsby (12-12-2003)
| Kommentar Fra : Ole Nielsby |
Dato : 12-12-03 01:50 |
|
Thomas Rokamp <no_spam@crax.dk> skrev:
> > > Jeg roder lidt med PHP og er stødt på funktioner til almindelige
> > > statements og prepared statements.
> > > Hvad er fordlee/ulemper ved dem hver især?
> >
> > Laver du det samme kald flere gange med forskellige parametre så rykker
> det
>
> Ja, men ikke umiddelbart efter hinanden.
> Jeg har de enkelte kald gemt væk i funktioner, der hver laver en ny
> prepared statement. Men der er måske ingen idé med dem, hvis
> hvert prepared statement kun udføres én gang pr. kald til funktionen?
Jo. Databasen kan sagtens cache mange prepared statements og
huske dem selvom der er kaldt andre indimellem.
Der er i øvrigt en anden fordel ved prepared statements: de forsimpler
overførsel af strengparametre, og det gør din webapplikation mere
robust.
Hvis du ikke bruger prepared statements eller på anden måde tjekker
alle strengparametre, så kommer din onde tvilling en dag og putter en
"drop database" ind i dit SQL-udtryk via en string-parameter som
kommer fra en forfalsket header
ON/Fjern sneglen fra min svaradresse
| |
Thomas Rokamp (12-12-2003)
| Kommentar Fra : Thomas Rokamp |
Dato : 12-12-03 16:30 |
|
> Jo. Databasen kan sagtens cache mange prepared statements og
> huske dem selvom der er kaldt andre indimellem.
Og de bliver ikke overskrevet eller "ødelagt" næste gang jeg laver en
prepared med samme tekst? Så bruger den bare den gamle?
> Der er i øvrigt en anden fordel ved prepared statements: de forsimpler
> overførsel af strengparametre, og det gør din webapplikation mere
> robust.
Der er altså ingen grundt til at checke på antallet at ' og " og
tilsvarende, når man bruger prepared?
> Hvis du ikke bruger prepared statements eller på anden måde tjekker
> alle strengparametre, så kommer din onde tvilling en dag og putter en
> "drop database" ind i dit SQL-udtryk via en string-parameter som
> kommer fra en forfalsket header
Er dette helt elimineret med prepared statements? Det er jo et rent helvede
at lave alle de checks...
/Thomas
| |
|
|