Ist so eine Klasse für MySQL-Datenverarbeitung gut?

Leichti · 23.06.2009, 16:05

Hallo!

Ich hab mich jetzt mal dran gemacht und etwas mehr in PHP5 und OOP eingelesen! Folgendes kam dabei heraus:

Datei: DB_Mysql.inc.php

PHP-Code:

  /* Klasse um mit einer Datenbank zu kommunizieren

 *

 * @autor Leuchtenmüller Manuel

 *

 *

 */

class DB_Mysql implements Datenbank {

 
    private $db_user;

    private $db_pw;

    private $db_host;

    private $db_table;

    

    private $prafix; // Datenbankpräfix

    

    protected $db_handler; // Datenbankhandler, dient um die Verbindung zu kennzeichnen

    public $row;

    

    public function __construct($user, $password, $host, $database, $prafix)

    {

        $this->db_user         = $user;

        $this->db_pw         = $password;

        $this->db_host         = $host;

        $this->db_database     = $database;

        $this->prafix         = $prafix;

            

        if(!$this->db_handler = mysql_connect($this->db_host, $this->db_user, $this->db_pw)) { // Verbinden zur Datenbank

            throw new MysqlException;

        }

        if(!mysql_select_db($this->db_database)) {

            throw new MysqlException;

        }

    }

    

    public function __destruct() 

    {

        mysql_close($this->db_handler);

    }

    

    /*

     *Einfache Query-Funktion mit Fehlerverarbeitung 

     */

    public function query($query)

    {

        if(($this->row = mysql_query($query, $this->db_handler))===false) {

            throw new MysqlException;

        }

        else {

            return true;

        }

    }

    

    /*

     *Etwas in eine Datenbank schreiben, Spalten und Werte werden benötigt in Form eines Arrays

     */

    public function insert_query($table, $werte_array)

    {

        try{

            if(empty($werte_array) or !is_array($werte_array)) {

                throw new MysqlException("Fehlerhafter Wert für einen Insert", 0);

            }

            

            $tmp = false;

            

            foreach($werte_array as $spalte=>$wert) { // Insert Werte und Spalten erstellen            

                if($tmp==false) {

                    $spalten     = $spalte;

                    $werte         = "'".$wert."'";

                    $tmp         = true;

                }

                else {

                    $spalten     .= " ,".$spalte;

                    $werte         .= " ,'".$wert."'";            

                }        

            }

            $query = "INSERT INTO {$this->prafix}{$table} ($spalten) VALUES ($werte)";

            

            $this->query($query);

        }

        catch(MysqlException $e) {

            echo "Errormessage: ".$e->message."<br>";

            echo "Errorcode: ".$e->code."<br>";

            echo "On Line: ".$e->getline()."<br>";

            exit;

        }        

    }

    

    /*

     *Eine Abfrage aus der Datenbank erstellen, der Query wird erstellt und auch verarbeitet

     */

    public function select_query($table, $select = "*", $options = array())

    {

        if(is_array($select)) {

            foreach($select as $key=>$spalte) {

                if(isset($select[$key+1])) {

                    @$spalten .= $spalte.", ";

                }

                else {

                    $spalten .= $spalte;

                }        

            }

            $select = $spalten;

        }

        

        $query = "SELECT $select FROM {$this->prafix}$table";

        

        if(isset($options["order_by"])) {

            $query .= " ORDER BY ".$options["order_by"];

        }        

        if(isset($options["limit_from"]) and isset($options["limit"])) {

            $query .= " LIMIT ".$options["limit_from"].", ".$options["limit"];

        }

        elseif(isset($options["limit"]) and !isset($options["limit_from"])) {

            $query .= " LIMIT ".$options["limit"];

        }    

                

        try {

            $this->query($query);

        }

        catch(MysqlException $e) {

            echo "Errormessage: ".$e->message."<br>";

            echo "Errorcode: ".$e->code."<br>";

            echo "On Line: ".$e->getline()."<br>";

            exit;

        }

    }    

    

    /* 

     * Ganzes Datenbank-Array erstellen

     */

    public function getFullArray() 

    {

        if(empty($this->row))

            return false;

        

        while($row = mysql_fetch_assoc($this->row)) {

            $this->full_array[] = $row;

        }

    }

    

    /* Weiter funktionen.... */

}

Datei interface.inc.php

PHP-Code:

  interface Datenbank {

    public function query($query);

    public function select_query($table);

    public function insert_query($table, $werte_array);    

    public function    getFullArray();

}

Datei MysqlException.inc.php

PHP-Code:

  class MysqlException extends Exception {

    public $message;

    public $code;

    public $backtrace;

    

    public function __construct($message=false, $code=false) 

    {

        if(!$message) {

            $this->message = mysql_error();

        }

        if(!$code) {

            $this->code = mysql_errno();

        }

        $this->backtrace = debug_backtrace();

    }

}

Und noch ein Beispiel für die Anwendung:

PHP-Code:

  error_reporting(E_ALL);

 
/* Interfaces einbinden */

require_once("interfaces.inc.php");

require_once("inc/DB_Mysql.inc.php");

require_once("error_handle/MysqlException.inc.php");

 
 
try {

$db = new DB_Mysql("root", "root", "localhost", "test", "welt_1_");

}

catch(MysqlException $e) {

    echo "Errormessage: ".$e->message."<br>";

    echo "Errorcode: ".$e->code."<br>";

    echo "On Line: ".$e->getline()."<br>";

}

 
 
$db->insert_query("user", array("username" => "ficker",

                                "freischaltcode" => "5sdasd"));

$db->select_query("user", 

                  "*", 

                  array("limit"        =>"10", 

                          "limit_from"=>"0",

                        "order_by"    =>"username ASC"));

$db->getFullArray();

print_r($db->full_array);

Meine Frage, was haltet ihr davon? Bisher? Bevor ich weiter mache..
Eventuell könnte man in getFullArray noch select_query direkt mit einbinden? Aber mich würde interessieren ob ich hier auf einem richtigen Weg bin?

mfg

Jens Clasen · 23.06.2009, 16:15

Völlig auf dem Holzweg würd ich dazu sagen:

1) Eine Klasse, die nur bestehende Funktionen einer Extension 1:1 abbildet benötigt niemand.
2) Alle Query-Ergebnisse der alten MySQL-Extension in ein Array zu lesen ist unsinnige Ressourcen-Verschwendung.
3) Dein Select-Query ist eindeutig zu unflexibel
4) Dein Insert-Query auch

Schau Dir mal bestehende Projekte wie MySQLi und PDO an, oder wirf mal nen Blick auf die diversen ORM-Projekte.

Gruß Jens

Leichti · 23.06.2009, 16:35

Zitat:

1) Eine Klasse, die nur bestehende Funktionen einer Extension 1:1 abbildet benötigt niemand.

Verstehe ich nicht ganz! Meinst du damit die Ausname?

Zitat:

2) Alle Query-Ergebnisse der alten MySQL-Extension in ein Array zu lesen ist unsinnige Ressourcen-Verschwendung.

Versteh ich auch nicht ganz..

Zitat:

3) Dein Select-Query ist eindeutig zu unflexibel

Da geb ich dir recht, liegt aber an mangelnden MySQL-Kentnissen.. Ich sollte mal das Manual durcharbeiten

Zitat:

4) Dein Insert-Query auch

Ich denke für meine Zwecke reicht es..

Jens Clasen · 23.06.2009, 16:42

Zu 1: Du bildest ausschließlich die Funktionen der MySQL-Extension von PHP ab. Dazu braucht es nun wirklich kein OOP. Die nächste Extension des nächsten DBMS kann eine ganz andere API haben, und spätestens dann kommst Du in die Bredouille, dass die Austauschbarkeit nicht mehr gewährleistet ist.

Zu 2: Die alte MySQL-Extension puffert die Ergebnisse der Abfrage intern sowieso im Speicher. Das musst Du nicht in Form eines Arrays noch ein zweites mal machen.

Zu 4: Eine Klasse ist dann eine gute Klasse, wenn sie nicht nur einem Anwender und Anwendungsfall dienen kann.

Gruß Jens

nikosch · 23.06.2009, 17:28

Naja, ganz verreissen würde ich die Klasse nicht. Immerhin werden hier schon mal die Verbindungsressource abstrahiert (einfach mysql_* und keine Ressource zu verwenden ist nämlich auch nicht die feine englische) und ein Exceptionhandling umgesetzt.
@Leichti: Zumindest die Querygestaltung solltest Du imho ganz auslagern und dafür eine Queryklassse schaffen. Damit bist Du wesentlich freier, was komplexe Anfragen betrifft.

getFullArray() scheint erstmal Overhead zu sein, es kommt aber darauf an, wofür man es benutzt
- niemand sagt, dass es nicht zusätzlich ein getLine () oder dergl geben kann
- die komplette Abfrage wird innerhalb der Anwendung gecacht. Bei mehrfachem Auslesen könnte man über einen Queryhash die fertige Datenmenge zurückgeben
- man könnte das Array über eine Cachefunktion zu einer Art Persistenzschicht ausbauen, indem die Daten bspw. in die Session wandern und beim nächsten Aufruf ohne DB-Abfrage zur Verfügung stehen.

erc · 30.06.2009, 19:51

Zitat:

Zitat von Jens Clasen

Zu 1: Du bildest ausschließlich die Funktionen der MySQL-Extension von PHP ab.

Ich seh da zumindestens schon mal ein besseres error handling...

Zitat:

Zitat von Jens Clasen

Die nächste Extension des nächsten DBMS kann eine ganz andere API haben, und spätestens dann kommst Du in die Bredouille, dass die Austauschbarkeit nicht mehr gewährleistet ist.

Hä? Die Klasse abstrahiert doch eindeutig die Datenbank API. Wo ist da das Problem eine andere Datenbank API einzubinden?

Zitat:

Zitat von Jens Clasen

Zu 4: Eine Klasse ist dann eine gute Klasse, wenn sie nicht nur einem Anwender und Anwendungsfall dienen kann.

Und beides kann man in diesem Fall bejahen. Als gut würde ich die Klasse aber drotzdem nicht bezeichen...

Zitat:

Meine Frage, was haltet ihr davon? Bisher? Bevor ich weiter mache..

Die Klasse ist in der Form recht primitiv, du verschenkst damit eine Menge funktionalität die dir die Datenbank API eigentlich zurverfügung stellt. Aber was fehlt wirst du noch in der Praxis feststellen.
Was mir noch aufgefallen ist:
-MysqlException... du hast DB_Mysql gegen ein Interface implementiert, das ist schonmal gut, aber du machst das Konzept durch die MysqlException wieder kapput. Du nimmst dir damit die möglichkeit DB_Mysql gegen DB_irgendwas zu ersetzen. (ausser DB_irgendwas wirft auch MysqlException's) Korrekt wäre es eine allgemeine Datenbank Exception zu implementieren.

PHP-Code:

  interface DB_Exception { 

         public function getLine() {

 
         }

         ....

}

PHP-Code:

  class MysqlException extends Exception implements DB_Exception {

 
}

PHP-Code:

  try {

$db = new DB_Mysql("root", "root", "localhost", "test", "welt_1_");

}

catch(DB_Exception $e) {

    echo "Errormessage: ".$e->message."<br>";

    echo "Errorcode: ".$e->code."<br>";

    echo "On Line: ".$e->getline()."<br>";

}

Die DB_Exception muss nicht unbedingt als interface implementiert werden, sondern kann auch eine Klasse sein die von Exception erbt. (und MysqlException würde dann von DB_Exception erben) Somit brauchst du nur eine Zeile ändern und kannst mit jeder DB arbeiten. (von SQL kompatibilitäts problemen mal abgesehen)

-getFullArray(): wie Jens Clasen schon gepostet hat ist das Ressourcen verschwendung. Das kann man zb umgehen indem man das resultset in ein Objekt packt und über das Objekt die Daten ausleist. Ganz primitv könnte das so aussehen:

PHP-Code:

  class mysql_resultset implements resultset {

     private $result;

     public function __construct($result) {

          $this->result = $result

     }

 
     public function fetch() {

            return mysql_fetch_assoc($this->result);

     }

}

 
...

 
$result = $db->query("SELECT * FROM foo");

while($daten =  $result->fetch()) {

 
}

Jens Clasen · 01.07.2009, 15:24

Zitat:

Zitat von erc

Ich seh da zumindestens schon mal ein besseres error handling...

Ich nicht.

Zitat:

Zitat von erc

Hä? Die Klasse abstrahiert doch eindeutig die Datenbank API. Wo ist da das Problem eine andere Datenbank API einzubinden?

Zum Beispiel an den Parametern des Verbindungsaufbaus. Versuch mal Dependency Injection mit diesem Constructor zu betreiben, wobei eigentlich schon ne einfache Factory-Methode langen würde, um das System zu Fall zu bringen.

Zitat:

Zitat von erc

Und beides kann man in diesem Fall bejahen.

Nein, kann man nicht. Lies es bitte im Zusammenhang:

Zitat:

Zitat von Jens Clasen

3) Dein Select-Query ist eindeutig zu unflexibel
4) Dein Insert-Query auch

Zitat:

Zitat von Leichti

Ich denke für meine Zwecke reicht es..

Zitat:

Zitat von Jens Clasen

Zu 4: Eine Klasse ist dann eine gute Klasse, wenn sie nicht nur einem Anwender und Anwendungsfall dienen kann.

Die Aussage bezieht sich direkt auf die zwei angesprochenen Methoden. Diese sind eben nicht für mehr als seinen Anwendungsfall zu gebrauchen, sprich nicht generisch genug.

Deinen restlichen Aussagen stimme ich im großen und ganzen zu.

IMHO fängt ein Datenbank-Wrapper dann an, langsam sinnvoll zu werden, wenn er mindestens die folgenden vier Bereiche umfasst:

Generierung von Queries bei gleichzeitiger Abstraktion der Parameter (Sprich also, eigene Statement- oder Query-Klasse mit Parameter-Filter)
Abstrahierte Ergebnisliste (in Deinem Beispiel also das ResultSet)
Abstrahierte Fehlerbehandlung
Abstrahierter Verbindungsaufbau
auch wichtig wäre mir, dass Transaktionen abbildbar sind

Bei mir bestünde ein rudimentärer Datenbank-Wrapper damit wohl aus mindestens vier Klassen...

Ansonsten fährt man nämlich einfach ohne DB-Wrapper (also für den Fall MySQL mit mysqli) besser...

Gruß Jens

mepeisen · 01.07.2009, 16:48

Vielleicht solltet ihr nochmal das Eingangspost lesen, denn der Anspruch des Autors war es nicht, die perfekte Bibliothek für den Datenbankzugriff zu schaffen, die in aller Zukunft jede Anforderung leicht und bequem ermöglicht und die man nie wieder anfassen muss.

"Dependency Injection" und OOP in einem Satz zu nennen und das so zu verwenden, dass eine Klasse per se schlecht ist, die Dependency Injection nicht erlaubt, hat einen gewissen Reiz. Aber sowas ist ungefähr als würde man argumentieren: "Die Kirsche schmeckt per se nicht wie eine Banane, also ist diese Kirsche einfach nur schlecht und gehört weggeworfen." Bitte vermischt hier nicht zwei unterschiedliche Ansätze, vor allem nicht, solange PHP nicht von Haus aus Dependency Injection udn AOP unterstützt. Mit dieser Argumentation wüprde man ungefähr grob geschätzt 99,9999% der PHP-Klassen und Bibliotheken als schlecht abstempeln.

Inwieweit eine Abstraktion der Queries sinnvoll ist, darüber lässt sich gut streiten. Ich denke, dass gute und populäre DB-APIs nicht ohne Grund immer beide Wege anbieten, sowohl die Übergabe eines SQL-Strings, als auch das generische Zusammenbauen eines Queries. Verbaut man sich das einfache Übergeben eines vorgefertigen SQL-Strings, wird man irgendwann einmal vor der Situation stehen, dass die Bibliothek einen bestimmten Query so ungeschickt zusammenbaut, dass der Datenbank-Optimizer so ungeschickt arbeitet, dass man die Performance in den Keller zieht.
Und wehe es behauptet nun einer, sowas würde es nie geben. Sowas könnt ihr meinetwegen in der Uni im Hörsaal behaupten. Die Praxis sieht so aus, dass die Art und Weise wie man Joins formuliert, oft auch Auswirkungen hat auf die Performance. Auch wenn das leider manchmal bedeutet, dass man Queries je nach Datenbanksystem umformulieren muss.

Jens Clasen · 02.07.2009, 01:24

99,999% aller in PHP implementierten DB-Wrapper für MySQL sehen meiner Erfahrung nach aus wie der im Eingangspost. Sinn hab ich davon die wenigsten machen sehen.

Ich sag damit nicht, dass die Klasse per se schlecht ist, weil sie *InsertBuzzwordHere* nicht kann, ich sag nur, dass sie überflüssig ist wie ein Kropf. Die Klasse bietet gegenüber nativen Lösungen wie mysqli oder von mir aus pdo absolut keinen Vorteil, also macht der Einsatz keinen Sinn. Der Einsatz würde erst dann Sinn machen, wenn sie einen Mehrwert bietet, also z.B. *InsertBuzzwordHere* kann. Die Möglichkeit einer Verwendung im Depedency Injection Pattern war ein Beispiel - grundsätzlich gilt das selbe auch schon bei einer einfachen Factory irgendwo (sagte ich übrigens oben auch schon), und selbst dass ist bei dieser fixen Form der Konfiguration schon nicht mehr ernsthaft möglich.

Was das Stichwort Abstraktion von Queries angeht: Selbst ne vorgetäuschte Implementierung des prepared Statement Konzeptes in Verbindung mit ner Cursor-Funktion irgendwo ist besser als garnichts. Die Mindestanforderung würd ich da einfach beim Parameter-Handling und dem Verarbeiten von Standard-SQL ansetzen. Ganz so übertreiben (wie mein letzter Post zugegebener maßen klingt) würd ich es da ja garnicht wollen...

Und nun noch mal zurück zur DI & co: Die Möglichkeit, DI, Factories und Registries zum Einsatz kommen zu lassen ist nicht allgemein und für jede Klasse (oder jede Handvoll davon) sinnig, bei Dingen die üblicherweise als generische Ressource irgendwo benötigt werden, macht es aber Sinn derartige Konzepte anbinden zu können. Sich von vornherein den Weg zu verschließen ist IMHO zu kurzsichtig. Nicht mehr und nicht weniger war die Aussage.

Ich persönlich weiß nicht, was der Anspruch des TE ist, ich maße mir aber an zu behaupten, dass der Anspruch der falsche ist, wenn die gepostete Klasse ihn erfüllt.

Leichti, bitte nimm diese Kritik nicht persönlich - ich weiß, das klingt alles erstmal relativ hart. Viele andere vor Dir haben genau das selbe implementiert, und da war es schon genau so unsinnig wie in Deinem Beispiel. Grade diese eng an eine Datenbank-Extension gekoppelten Datenbank-Wrapper sind genauso eine Modesünde, wie es Template-Engines mit aufwendiger eigener Syntax lange Zeit waren. Das ist nur eben einfach kein Grund, auf den selben Zug auch auf zu springen, und davon versuch ich halt zu warnen.

Gruß Jens

mepeisen · 02.07.2009, 10:39

Also ich denke beim Konstruktor oder der Art und Weise, wie man von einer Konfiguration auf das Anlegen des DB-Verbindungsobjektes kommt, da dürften wir uns einig sein. Das ist schlecht, denn das Beispiel-Script muss folgendes wissen:
a) Ich brauche eine MySQL-Verbindung
b) Das braucht ein Passwort, einen Hostnamen usw.
Was, wenn nun plötzlich mysqli als extension genutzt werden soll und der Server auf einem alternativen Port läuft? Hmmm. Wurde ja schon von meinen Vorgängern erklärt, dass sowas nicht gut ist...
Ich selbst kann da beispielsweise das Zend-Framework empfehlen. Dererlei Konzepte, einfach ein Array mitzugeben, was so eins zu eins aus beispielsweise einer Ini-Datei stammt, lässt für jeden Datenbanktreiber genug Spielraum und die Anwendung braucht keinerlei spezialisierte Kenntnisse über die Art der Daten, die der DB-Treiber zum Verbindungsaufbau benötigt.
Es ist schlicht und funktioniert wohl auch in Zukunft in nahezu jedem Fall.

Also da ja schon zumindest eine Abstraktion vorliegt über ein Interface kann man ja durchaus schon von einem erfüllten Ziel sprechen. Wichtig ist nicht die Innerei der Klasse, sondern der Vertrag, den du mit ihr eingehst. Zu deutsch: Die Methodensignaturen. Und auch wenn du erst einmal wenig Funktionalität mit den Methoden anbietest, ist es doch ein Umstand: Jedes andere Datenbanksystem kann einen Wrapper auf der Basis des Interfaces implementieren. Und damit brauchst du nur noch den Treiber austauschen, in der Anwendung bleibt alles gleich. Der Vorteil gegenüber dem puren Verwenden der DB-Funktionen: Sie sind kompatibel.

Einfaches Beispiel:
Tausche mal die Datenbank von MySQL auf MsSQL. Du wirst feststellen, dass du mit der Wrapper-Klasse in deiner Anwendung selbst nix ändern musst.
Aber die Situation ohne Wrapper: Hattest du vorher die MySQL-Funktionen als OOP selbst verwendet, wirst du nun in der kompletten Anwendung die ganzen Aufrufe auf den MySQL-Verbindungsobjekten und Result-Objekten durch einfache Funktionsaufrufe ersetzen müssen.
Bei einem solchen Fall hätte sich der Wrapper bereits bezahlt gemacht beim Aufwand...

In meinen Augen haben Wrapper genau deshalb bereits durchaus eine Existenzberechtigung.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
MySQL Verbindung zu fremden Server	Xanatus	Datenbanken	5	27.05.2009 14:13
[Erledigt] Kann keine Umlaute im mysql client eingeben	Oger	Datenbanken	9	02.04.2009 11:54
MySQL Konsole und Umlaute unter Windows [LÖSUNG]	f4ckm5	Datenbanken	8	30.03.2009 22:10
[Erledigt] Eine klasse einbinden	newWorldOrder	PHP Tipps 2009	2	23.02.2009 19:32
MySQL Klasse	Gödda	PHP Tipps 2009	8	17.02.2009 01:56
Problem bei Umstellung auf MySQL 5	bettina	Datenbanken	13	21.01.2009 10:00
tutorial mysql klassen im oop projekt	phpdummi	Beitragsarchiv	4	17.01.2007 20:17
MySQL - Klasse: Wie da mysql_close benutzen	Igäl	PHP Tipps 2006	5	01.10.2006 23:09
mysql klasse - handling mehrerer connections	mrSpok	PHP Tipps 2006	5	14.04.2006 01:05
MySQL Server startet nicht mehr richtig...		Datenbanken	16	03.03.2006 19:40
Kein Zugriff über ODBC mit der IP-Adresse auf MySql DB		Datenbanken	4	09.02.2006 11:04
[Erledigt] not allowed to connect to this MySQL server		PHP Tipps 2005-2	2	23.09.2005 18:34
Suche Tipps für Persormance-Steigerung (Geld für Nützliches)		Beitragsarchiv	18	16.08.2005 10:57
MYSQL läuft nur wenn /tmp auf 777		Datenbanken	5	06.07.2005 08:38
mysql root passwort vergessen		Datenbanken	1	29.05.2005 11:33

23.06.2009, 16:05
Leichti Benutzer Registriert seit: 18.06.2009 Beiträge: 42 PHP-Kenntnisse: Fortgeschritten	Ist so eine Klasse für MySQL-Datenverarbeitung gut? Hallo! Ich hab mich jetzt mal dran gemacht und etwas mehr in PHP5 und OOP eingelesen! Folgendes kam dabei heraus: Datei: DB_Mysql.inc.php PHP-Code: /* Klasse um mit einer Datenbank zu kommunizieren * * @autor Leuchtenmüller Manuel * * / class DB_Mysql implements Datenbank { private $db_user; private $db_pw; private $db_host; private $db_table; private $prafix; // Datenbankpräfix protected $db_handler; // Datenbankhandler, dient um die Verbindung zu kennzeichnen public $row; public function __construct($user, $password, $host, $database, $prafix) { $this->db_user = $user; $this->db_pw = $password; $this->db_host = $host; $this->db_database = $database; $this->prafix = $prafix; if(!$this->db_handler = mysql_connect($this->db_host, $this->db_user, $this->db_pw)) { // Verbinden zur Datenbank throw new MysqlException; } if(!mysql_select_db($this->db_database)) { throw new MysqlException; } } public function __destruct() { mysql_close($this->db_handler); } / Einfache Query-Funktion mit Fehlerverarbeitung / public function query($query) { if(($this->row = mysql_query($query, $this->db_handler))===false) { throw new MysqlException; } else { return true; } } /* Etwas in eine Datenbank schreiben, Spalten und Werte werden benötigt in Form eines Arrays / public function insert_query($table, $werte_array) { try{ if(empty($werte_array) or !is_array($werte_array)) { throw new MysqlException("Fehlerhafter Wert für einen Insert", 0); } $tmp = false; foreach($werte_array as $spalte=>$wert) { // Insert Werte und Spalten erstellen if($tmp==false) { $spalten = $spalte; $werte = "'".$wert."'"; $tmp = true; } else { $spalten .= " ,".$spalte; $werte .= " ,'".$wert."'"; } } $query = "INSERT INTO {$this->prafix}{$table} ($spalten) VALUES ($werte)"; $this->query($query); } catch(MysqlException $e) { echo "Errormessage: ".$e->message."<br>"; echo "Errorcode: ".$e->code."<br>"; echo "On Line: ".$e->getline()."<br>"; exit; } } /* Eine Abfrage aus der Datenbank erstellen, der Query wird erstellt und auch verarbeitet / public function select_query($table, $select = "", $options = array()) { if(is_array($select)) { foreach($select as $key=>$spalte) { if(isset($select[$key+1])) { @$spalten .= $spalte.", "; } else { $spalten .= $spalte; } } $select = $spalten; } $query = "SELECT $select FROM {$this->prafix}$table"; if(isset($options["order_by"])) { $query .= " ORDER BY ".$options["order_by"]; } if(isset($options["limit_from"]) and isset($options["limit"])) { $query .= " LIMIT ".$options["limit_from"].", ".$options["limit"]; } elseif(isset($options["limit"]) and !isset($options["limit_from"])) { $query .= " LIMIT ".$options["limit"]; } try { $this->query($query); } catch(MysqlException $e) { echo "Errormessage: ".$e->message."<br>"; echo "Errorcode: ".$e->code."<br>"; echo "On Line: ".$e->getline()."<br>"; exit; } } / * Ganzes Datenbank-Array erstellen / public function getFullArray() { if(empty($this->row)) return false; while($row = mysql_fetch_assoc($this->row)) { $this->full_array[] = $row; } } / Weiter funktionen.... / } Datei interface.inc.php* PHP-Code: `interface Datenbank { public function query($query); public function select_query($table); public function insert_query($table, $werte_array); public function getFullArray(); }` Datei MysqlException.inc.php PHP-Code: `class MysqlException extends Exception { public $message; public $code; public $backtrace; public function __construct($message=false, $code=false) { if(!$message) { $this->message = mysql_error(); } if(!$code) { $this->code = mysql_errno(); } $this->backtrace = debug_backtrace(); } }` Und noch ein Beispiel für die Anwendung: PHP-Code: error_reporting(E_ALL); /* Interfaces einbinden / require_once("interfaces.inc.php"); require_once("inc/DB_Mysql.inc.php"); require_once("error_handle/MysqlException.inc.php"); try { $db = new DB_Mysql("root", "root", "localhost", "test", "welt_1_"); } catch(MysqlException $e) { echo "Errormessage: ".$e->message."<br>"; echo "Errorcode: ".$e->code."<br>"; echo "On Line: ".$e->getline()."<br>"; } $db->insert_query("user", array("username" => "ficker", "freischaltcode" => "5sdasd")); $db->select_query("user", "", array("limit" =>"10", "limit_from"=>"0", "order_by" =>"username ASC")); $db->getFullArray(); print_r($db->full_array); Meine Frage, was haltet ihr davon? Bisher? Bevor ich weiter mache.. Eventuell könnte man in getFullArray noch select_query direkt mit einbinden? Aber mich würde interessieren ob ich hier auf einem richtigen Weg bin? mfg


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

23.06.2009, 16:15
Jens Clasen Erfahrener Benutzer Registriert seit: 19.06.2009 Beiträge: 837 PHP-Kenntnisse: Fortgeschritten	Völlig auf dem Holzweg würd ich dazu sagen: 1) Eine Klasse, die nur bestehende Funktionen einer Extension 1:1 abbildet benötigt niemand. 2) Alle Query-Ergebnisse der alten MySQL-Extension in ein Array zu lesen ist unsinnige Ressourcen-Verschwendung. 3) Dein Select-Query ist eindeutig zu unflexibel 4) Dein Insert-Query auch Schau Dir mal bestehende Projekte wie MySQLi und PDO an, oder wirf mal nen Blick auf die diversen ORM-Projekte. Gruß Jens

23.06.2009, 16:42
Jens Clasen Erfahrener Benutzer Registriert seit: 19.06.2009 Beiträge: 837 PHP-Kenntnisse: Fortgeschritten	Zu 1: Du bildest ausschließlich die Funktionen der MySQL-Extension von PHP ab. Dazu braucht es nun wirklich kein OOP. Die nächste Extension des nächsten DBMS kann eine ganz andere API haben, und spätestens dann kommst Du in die Bredouille, dass die Austauschbarkeit nicht mehr gewährleistet ist. Zu 2: Die alte MySQL-Extension puffert die Ergebnisse der Abfrage intern sowieso im Speicher. Das musst Du nicht in Form eines Arrays noch ein zweites mal machen. Zu 4: Eine Klasse ist dann eine gute Klasse, wenn sie nicht nur einem Anwender und Anwendungsfall dienen kann. Gruß Jens

23.06.2009, 17:28
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Naja, ganz verreissen würde ich die Klasse nicht. Immerhin werden hier schon mal die Verbindungsressource abstrahiert (einfach mysql_* und keine Ressource zu verwenden ist nämlich auch nicht die feine englische) und ein Exceptionhandling umgesetzt. @Leichti: Zumindest die Querygestaltung solltest Du imho ganz auslagern und dafür eine Queryklassse schaffen. Damit bist Du wesentlich freier, was komplexe Anfragen betrifft. getFullArray() scheint erstmal Overhead zu sein, es kommt aber darauf an, wofür man es benutzt - niemand sagt, dass es nicht zusätzlich ein getLine () oder dergl geben kann - die komplette Abfrage wird innerhalb der Anwendung gecacht. Bei mehrfachem Auslesen könnte man über einen Queryhash die fertige Datenmenge zurückgeben - man könnte das Array über eine Cachefunktion zu einer Art Persistenzschicht ausbauen, indem die Daten bspw. in die Session wandern und beim nächsten Aufruf ohne DB-Abfrage zur Verfügung stehen. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

01.07.2009, 16:48
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.234 PHP-Kenntnisse: Fortgeschritten	Vielleicht solltet ihr nochmal das Eingangspost lesen, denn der Anspruch des Autors war es nicht, die perfekte Bibliothek für den Datenbankzugriff zu schaffen, die in aller Zukunft jede Anforderung leicht und bequem ermöglicht und die man nie wieder anfassen muss. "Dependency Injection" und OOP in einem Satz zu nennen und das so zu verwenden, dass eine Klasse per se schlecht ist, die Dependency Injection nicht erlaubt, hat einen gewissen Reiz. Aber sowas ist ungefähr als würde man argumentieren: "Die Kirsche schmeckt per se nicht wie eine Banane, also ist diese Kirsche einfach nur schlecht und gehört weggeworfen." Bitte vermischt hier nicht zwei unterschiedliche Ansätze, vor allem nicht, solange PHP nicht von Haus aus Dependency Injection udn AOP unterstützt. Mit dieser Argumentation wüprde man ungefähr grob geschätzt 99,9999% der PHP-Klassen und Bibliotheken als schlecht abstempeln. Inwieweit eine Abstraktion der Queries sinnvoll ist, darüber lässt sich gut streiten. Ich denke, dass gute und populäre DB-APIs nicht ohne Grund immer beide Wege anbieten, sowohl die Übergabe eines SQL-Strings, als auch das generische Zusammenbauen eines Queries. Verbaut man sich das einfache Übergeben eines vorgefertigen SQL-Strings, wird man irgendwann einmal vor der Situation stehen, dass die Bibliothek einen bestimmten Query so ungeschickt zusammenbaut, dass der Datenbank-Optimizer so ungeschickt arbeitet, dass man die Performance in den Keller zieht. Und wehe es behauptet nun einer, sowas würde es nie geben. Sowas könnt ihr meinetwegen in der Uni im Hörsaal behaupten. Die Praxis sieht so aus, dass die Art und Weise wie man Joins formuliert, oft auch Auswirkungen hat auf die Performance. Auch wenn das leider manchmal bedeutet, dass man Queries je nach Datenbanksystem umformulieren muss. __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

02.07.2009, 01:24
Jens Clasen Erfahrener Benutzer Registriert seit: 19.06.2009 Beiträge: 837 PHP-Kenntnisse: Fortgeschritten	99,999% aller in PHP implementierten DB-Wrapper für MySQL sehen meiner Erfahrung nach aus wie der im Eingangspost. Sinn hab ich davon die wenigsten machen sehen. Ich sag damit nicht, dass die Klasse per se schlecht ist, weil sie InsertBuzzwordHere nicht kann, ich sag nur, dass sie überflüssig ist wie ein Kropf. Die Klasse bietet gegenüber nativen Lösungen wie mysqli oder von mir aus pdo absolut keinen Vorteil, also macht der Einsatz keinen Sinn. Der Einsatz würde erst dann Sinn machen, wenn sie einen Mehrwert bietet, also z.B. InsertBuzzwordHere kann. Die Möglichkeit einer Verwendung im Depedency Injection Pattern war ein Beispiel - grundsätzlich gilt das selbe auch schon bei einer einfachen Factory irgendwo (sagte ich übrigens oben auch schon), und selbst dass ist bei dieser fixen Form der Konfiguration schon nicht mehr ernsthaft möglich. Was das Stichwort Abstraktion von Queries angeht: Selbst ne vorgetäuschte Implementierung des prepared Statement Konzeptes in Verbindung mit ner Cursor-Funktion irgendwo ist besser als garnichts. Die Mindestanforderung würd ich da einfach beim Parameter-Handling und dem Verarbeiten von Standard-SQL ansetzen. Ganz so übertreiben (wie mein letzter Post zugegebener maßen klingt) würd ich es da ja garnicht wollen... Und nun noch mal zurück zur DI & co: Die Möglichkeit, DI, Factories und Registries zum Einsatz kommen zu lassen ist nicht allgemein und für jede Klasse (oder jede Handvoll davon) sinnig, bei Dingen die üblicherweise als generische Ressource irgendwo benötigt werden, macht es aber Sinn derartige Konzepte anbinden zu können. Sich von vornherein den Weg zu verschließen ist IMHO zu kurzsichtig. Nicht mehr und nicht weniger war die Aussage. Ich persönlich weiß nicht, was der Anspruch des TE ist, ich maße mir aber an zu behaupten, dass der Anspruch der falsche ist, wenn die gepostete Klasse ihn erfüllt. Leichti, bitte nimm diese Kritik nicht persönlich - ich weiß, das klingt alles erstmal relativ hart. Viele andere vor Dir haben genau das selbe implementiert, und da war es schon genau so unsinnig wie in Deinem Beispiel. Grade diese eng an eine Datenbank-Extension gekoppelten Datenbank-Wrapper sind genauso eine Modesünde, wie es Template-Engines mit aufwendiger eigener Syntax lange Zeit waren. Das ist nur eben einfach kein Grund, auf den selben Zug auch auf zu springen, und davon versuch ich halt zu warnen. Gruß Jens

02.07.2009, 10:39
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.234 PHP-Kenntnisse: Fortgeschritten	Also ich denke beim Konstruktor oder der Art und Weise, wie man von einer Konfiguration auf das Anlegen des DB-Verbindungsobjektes kommt, da dürften wir uns einig sein. Das ist schlecht, denn das Beispiel-Script muss folgendes wissen: a) Ich brauche eine MySQL-Verbindung b) Das braucht ein Passwort, einen Hostnamen usw. Was, wenn nun plötzlich mysqli als extension genutzt werden soll und der Server auf einem alternativen Port läuft? Hmmm. Wurde ja schon von meinen Vorgängern erklärt, dass sowas nicht gut ist... Ich selbst kann da beispielsweise das Zend-Framework empfehlen. Dererlei Konzepte, einfach ein Array mitzugeben, was so eins zu eins aus beispielsweise einer Ini-Datei stammt, lässt für jeden Datenbanktreiber genug Spielraum und die Anwendung braucht keinerlei spezialisierte Kenntnisse über die Art der Daten, die der DB-Treiber zum Verbindungsaufbau benötigt. Es ist schlicht und funktioniert wohl auch in Zukunft in nahezu jedem Fall. Also da ja schon zumindest eine Abstraktion vorliegt über ein Interface kann man ja durchaus schon von einem erfüllten Ziel sprechen. Wichtig ist nicht die Innerei der Klasse, sondern der Vertrag, den du mit ihr eingehst. Zu deutsch: Die Methodensignaturen. Und auch wenn du erst einmal wenig Funktionalität mit den Methoden anbietest, ist es doch ein Umstand: Jedes andere Datenbanksystem kann einen Wrapper auf der Basis des Interfaces implementieren. Und damit brauchst du nur noch den Treiber austauschen, in der Anwendung bleibt alles gleich. Der Vorteil gegenüber dem puren Verwenden der DB-Funktionen: Sie sind kompatibel. Einfaches Beispiel: Tausche mal die Datenbank von MySQL auf MsSQL. Du wirst feststellen, dass du mit der Wrapper-Klasse in deiner Anwendung selbst nix ändern musst. Aber die Situation ohne Wrapper: Hattest du vorher die MySQL-Funktionen als OOP selbst verwendet, wirst du nun in der kompletten Anwendung die ganzen Aufrufe auf den MySQL-Verbindungsobjekten und Result-Objekten durch einfache Funktionsaufrufe ersetzen müssen. Bei einem solchen Fall hätte sich der Wrapper bereits bezahlt gemacht beim Aufwand... In meinen Augen haben Wrapper genau deshalb bereits durchaus eine Existenzberechtigung. __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih