extends MySQL

Die quote komt van een user.
Dat is niet wat de manual voor schrijft.
De manual zegt alleen dat het een vorige connectie sluit meer niet.

Hoewel de meeste user comments goede tips bevatten is deze van 6 jaar geleden.
Het kan natuurlijk zijn dat de user een berg connecties naar de database maakt waardoor het allemaal erg traag werd, en ja dan is het logisch dat je de close functie gebruikt om de VORIGE connectie te sluiten.

Het openen en sluiten van een database connectie heeft iets van doen met veiligheid.
Je kan zowel met een verkeerd php script, dan wel met een verkeerde (onveilige) query je site hackbaar maken. Ik kan legio aan voorbeelden schrijven hoe het onveilig zou kunnen worden, maar dat doe ik niet. :)

Beter is om je tips te geven om het veilig te maken.

Dwing in je php code af wat verwacht word.
Dus als jij een invoerveld hebt wat verwacht dat alleen nummers bevat dan moet je daarop controleren.
Een string een minimale en maximale lengte geven bijvoorbeeld.
Verwacht je geen tags in je invoer verwijder ze, of controleer er op en geef een foutmelding.

PHP heeft tegenwoordig een filter_var() functie, dat maakt het leven al een stuk aangenamer.
(http://php.net/manual/en/function.filter-var.php)

Als alles klopt wat je verwacht, dan zet je het pas in de database.
Zowel PDO als mysqli hebben de prepared statement functies aan boord.
Die zorgen er voor dat je inhoud correct een veilig in de database komen.

En dan moet het op server nivo ook allemaal nog goed geregeld zijn, maar dat is voor dit topic ietsje te veel van het goede. ;)
EDIT
Ik zie net dat je hebt zitten editen in je post..
Dat artikel is van March 16, 2004.. Dat is van toen ik nog haar op mijn hoofd had.
Dus als jij met een versie werkt die uit die tijd stamt dan word het tijd om eens wat te updaten. Dat is allemaal niet meer relevant.
Overigens is het wel zo dat mysql_connect niet meer werkt in de nieuwste versie, daarom word hier vaak het advies gegeven om over te stappen naar mysqli of PDO.
PDO is leuk als je bijvoorbeeld een zou willen overstappen naar een andere database.
Bijvoorbbeeld SQLite, of postgres.

Goed verhaal Bart.
Ik wel er wel even iets aan toevoegen.

Prepared statements worden op de een af andere manier heilig beschouwd in de PHP wereld.
Dat zijn ze niet en in veel gevallen volkomen overbodig. Het is namelijk zo dat zowel MySQli als PDO eerst een querie naar de db-server stuurt, die wordt geëvalueerd en er wordt een query plan aan gehangen. Dan krijgt de client een pointer naar terug waarna met behulp van die pointer de query telkens uitgevoerd met de verschillende parameters.
Bij eenmalige query's kan je het binden van die parameters net zo goed oplossen met een escape of type casting.

Bedankt voor de goede tips.

Ik zie net dat je hebt zitten editen in je post..

Het was een toevoeging of aanvulling op het bericht.

Voor de veiligheid doe ik alles in combinatie met regular expressions.
Mijn laptop is laatst stuk gegaan en ik gebruik nu versie: 5.6.21
Ik ga proberen over te stappen op PDO maar ben daar nog over aan het lezen.
Wat ik me afvraag bij PDO is of daar ook een real_escape_string in zit en of dat nog nodig is.
De prepared statements zitten er inderdaad wel in maar ik vraag me af of dit een goede vervanger is van de real_escape_string.

[size=xsmall]Toevoeging op 09/01/2015 20:35:17:[/size]

En het antwoord zat in het bericht hiervoor die ik nog niet gelezen had.
Bedankt voor de tips.

@Ger, Dank doe mijn best. :)
Dat is een hele goede toevoeging. Want type casting en of escape is natuurlijk ook heel goed mogelijk.
De uitleg heb ik mijzelf eigenlijk nooit in verdiept hoe het prepared statement ding eigenlijk zijn werk doet. Dus ben eigenlijk wel heel blij dat je het even opmerkt hoe dat ding eigenlijk onder water werkt.
Dank daarvoor.

Mijn laptop is laatst stuk gegaan en ik gebruik nu versie: 5.6.21

Bedoel je php of mysql?

Voor de veiligheid doe ik alles in combinatie met regular expressions.

Poeh.. jij liever dan ik :)
Iets met een allergie voor regular expressions..

De prepared statements zitten er inderdaad wel in maar ik vraag me af of dit een goede vervanger is van de real_escape_string.

PDO heeft ook een escape_string optie hoor. :)
http://php.net/manual/en/pdo.quote.php

Ik bedoelde de MySQL server versie.

Via
Kun je regular expressies testen wat het 1000 x makkelijker maakt vind ik persoonlijk.
Handig dat de escape string er ook in zit. Bedankt.

Toch nog even een waarschuwing bij dit eerdere voorbeeld:

<?php
class profiel
{
   protected $db;

   public function __construct()
   {
      $this->db = new MySQL;
   }
}
?>

De klasse zelf opent hier een databaseverbinding en plaats van een elders geopende database te hergebruiken. Gevolg daarvan kan een bekend performance-probleem veroorzaken: 45 queries uitvoeren via 45 databaseverbindingen voor één enkele webpagina.

In dat geval kán het vroegtijdig sluiten van de verbindingen helpen, al is een ander OOP-ontwerp maken natuurlijk beter.

deels is dit waar:

het is overzichtelijker als je $this->db = db::getDbVerbinding(); oid gebruikt.

Maar als je via php meerdere connecties met dezelfde inloggegevens gebruikt, wordt de bestaande verbinding opnieuw gebruikt en krijg je dus niet 10 exact dezelfde verbindingen.

Wel is het een beetje eng, wat hierboven gedaan wordt: bij het destructen van een object wordt de verbinding gesloten.
Maar het zou een beetje jammer zijn als het destructen van een object zou zorgen dat alle andere objecten ineens geen db-verbinding meer hebben.

Sorry voor mijn late reactie.
Bedankt voor de waarschuwing en uitleg.
Wat ik nu van plan ben om te doen is ongeveer dit:

<?php
include_once "Statisch.class.php";

class Profiel{
private $host;
private $database;
private $username;
private $password;

public function __construct(){
$this->host = Statisch::getHost();
$this->database = Statisch::getDb();
$this->username = Statisch::getUser();
$this->password = Statisch::getDb();

try
{
$this->db = new PDO("mysql:host=". $this->host .";dbname=". $this->database ."",$this->username, $this->password);
}
catch(PDOException $e)
{
echo '<pre>';
echo 'Regelnummer: '.$e->getLine().'<br>';
echo 'Bestand: '.$e->getFile().'<br>';
echo 'Foutmelding: '.$e->getMessage().'<br>';
echo '</pre>';
}
}
}

$object = new Profiel();
?>

Maar het zou een beetje jammer zijn als het destructen van een object zou zorgen dat alle andere objecten ineens geen db-verbinding meer hebben.

Daarbij vraag ik me af hoe dat zit tussen de stack en de heap.

Wat ik tussen stack en heap begrijp is dat het bij $object pas in de heap terecht komt.
Maar ik begrijp dan nog niet of dan ook alles in de heap komt inclusief de include_once "Statisch.class.php";
of als er een object extends wordt met een andere class en of die dan ook meteen in de heap terecht komt.