While ... Update sql

[nietaL]

[src=php]$stufen = array("I", "II", "III", "IV", "V", "VI");

while (mysqli_fetch_array($gebiete_west))
{
mysqli_query($db, "UPDATE gebiete SET partei = 'west' WHERE partei != 'ost'");
$zufallstufe = rand(0, 5);
mysqli_query($db, "UPDATE gebiete SET upgrade = '".$stufen[$zufallstufe]."' WHERE partei != 'ost'");
echo "Prüfung: ".$stufen[$zufallstufe];
}[/src]


Es wird eine Liste von Gebieten ausgelesen, denen eine röm. Zufallszahl von I bis VI zugeteilt werden soll.
Die ausgegebene Prüfung ergibt eine Vielzahl von verschiedenen röm. Zahlen. In die Datenbank wird aber nur eine römische Zahl für alle Gebiete, die !='ost' sind. Ich raff das nicht. Übrigens ist es weder die erste noch die letzte der zufallsgenerierten röm. Zahlen, die in die DB geschrieben wird.

Ich glaube, ich verstehe WHILE nicht so richtig...

 

[Timon3]

Dein Denkfehler liegt darin, dass du mehr trennen musst zwischen deinem PHP-Server und deinem MySQL-Server. mysqli_fetch_array holt dir immer wieder eine neue Ergebniszeile aus einem Objekt, welches du per Abfrage bekommen hast. Im Endeffekt läuft deine while-Schleife so oft wie viele Reihen es gibt - das könntest du aber auch viel einfacher machen, indem du ein COUNT machst und per for darüber läufst.

Das tatsächliche Problem ist aber ein anderes. In deinem zweiten Update lässt du ein Update über alle gebiete laufen, welche eine partei != "ost" haben. Das bedeutet nicht, dass eine einzelne Zeile geupdatet wird, sondern alle auf einmal. Du sagst im Endeffekt dem MySQL-Server "Schreib überall 4 rein. Ne, 2. Ne, 1.". Du müsstest die Zeile, die du über mysqli_fetch_array bekommst, zwischenspeichern. Darin hast du vermutlich/hoffentlich eine ID. Anstatt abzufragen "WHERE partei != 'ost'" solltest du dann abfragen "WHERE partei != 'ost' AND id = :id", dann wird das nur für die Zeile gemacht, für die du es willst.

Bezüglich dem Code gibt es übrigens ein paar Sachen, die du beachten solltest. Zuerst solltest du statt mysqli PDO benutzen, im Idealfall auch nicht im prozeduralen, sondern im objektorientierten Stil. Link Zudem, was noch viel viel wichtiger ist: Niemals MySQL-Befehle durch aneinanderhängen von Strings erzeugen solange irgendwie möglich! Diszipliniere dich, immer (wenn möglich, es gibt einige kleine Ausnahmen) stattdessen Prepared Statements zu verwenden.

 

[theSplit]

Ich würde das hier verwenden um zu identifizieren um welche "id" es sich beim letzten Update Query handelt:
http://php.net/manual/de/mysqli.insert-id.php

Damit kannst du theoretisch ganz leicht abfragen, welche "id" beim letzten Update betroffen war, also nach:
[src=php]mysqli_query($db, "UPDATE gebiete SET partei = 'west' WHERE partei != 'ost'");[/src]

die letzte "id" mittels Insert-id Abfragen, ist keine Zeile betroffen, ist der Rückgabewert "0"...
Wenn der Wert nicht 0 ist, hier
[src=php]mysqli_query($db, "UPDATE gebiete SET upgrade = '".$stufen[$zufallstufe]."' WHERE partei != 'ost' AND id=lastIdEinsetzen"); // Last Id nutzen, vorher auf != 0 pruefen[/src]

Ansonsten auch die Tips von GameChamp befolgen was die Queries und Iteration angeht, aber man kann auch mysqli statt PDO verwenden...

 

[Roin]

Bezüglich dem Code gibt es übrigens ein paar Sachen, die du beachten solltest. Zuerst solltest du statt mysqli PDO benutzen, im Idealfall auch nicht im prozeduralen, sondern im objektorientierten Stil. Link

Was spricht gegen mysqli? Ich nutze meistens einfach mysqli, wieso sollte man bevorzugt PDO nutzen? Ist das nicht nur persönliche Präferenz?

 

[Timon3]

@Roin: Ganz simpel: Vergleich mal die API. Alleine Prepared Statements (die zumindest in meinen Codebases einen Großteil der Queries darstellen) sind unter PDO weitaus angenehmer zu benutzen.

Gegen mysqli selbst spricht nichts, es gibt halt Zugriff auf die Methoden der C-Bibliothek. Es abstrahiert aber fast nichts weg, das meiste wird dem Nutzer überlassen. Wenn man sich was darum baut, schön, dann ist es auch ganz gut benutzbar. Aber ohne einen Layer Fluff darum ist PDO wesentlich besser zu benutzen.

 

[Roin]

@GameChamp98:
Ich benutze mit mysqli entweder nur ganz einfache SELECT-Abfragen ohne Userinput oder Prepared Statements - und die finde ich in PDO jetzt nicht wirklich kürzer oder sowas... Ich verstehe nicht, wo du da den Vorteil siehst - außer das man am Anfang die Datenbankverbindung minimal umschreibt und dann auch andere Systeme als MySQL nutzen kann.

Entweder:
[src=php]@$db = new mysqli('localhost', 'user', 'pass');

// Verbindung überprüfen
if (mysqli_connect_errno()) {
printf("Verbindung fehlgeschlagen: %s\n", mysqli_connect_error());
exit();
}

$db->select_db('database');

if($stmt = $db->prepare("SELECT id FROM footable WHERE t1.LoginName=? AND t2.LoginPass=?")) {
$logname = filter_input(INPUT_POST, 'logname', FILTER_SANITIZE_STRING);
$logpass = filter_input(INPUT_POST, 'logpass', FILTER_SANITIZE_STRING);

/* bind parameters for markers */
$stmt->bind_param("ss", $logname, password_hash($logpass, PASSWORD_DEFAULT));

/* execute query */
$stmt->execute();

/* bind result variables */
$stmt->bind_result($id);

/* fetch value */
$stmt->fetch();

/* close statement */
$stmt->close();
//crazy shit with $id[/src]
oder:
[src=php]$pdo = new PDO('mysql:host=localhost;dbname=database', 'user', 'pass');

if($stmt = $pdo->prepare("SELECT id FROM footable WHERE t1.LoginName=:logname AND t2.LoginPass=:logpass")) {
$logname = filter_input(INPUT_POST, 'logname', FILTER_SANITIZE_STRING);
$logpass = filter_input(INPUT_POST, 'logpass', FILTER_SANITIZE_STRING);

/* bind parameters for markers */
$stmt->bindParam(':logname', $logname, PDO::PARAM_STRING);
$stmt->bindParam(':logpass', $logpass, PDO::PARAM_STRING);

/* execute query */
$stmt->execute();

/* bind result variables */
//$stmt->bind_result($id); //das ist falsch, das gibt es in PDO nicht

/* fetch value */
$row = $stmt->fetch(PDO::FETCH_ASSOC); //ergänzt
$id = $row['id'];

/* close statement */
//$stmt->close(); //Die Funktion heißt für PDO anders
$stmt->closeCursor();
//crazy shit with $id[/src]
Möglicherweise ist da ein Fehler drin, aber viel verändern tut sich nicht und "schöner" wird es dadurch mMn ebenfalls nicht. Die Verbindung zur Datenbank baut man einmal am Anfang des Scripts auf - da macht das keinen wirklichen Unterschied. Alles Weitere ist mehr oder minder gleich, oder nicht?

EDIT: Quellcode für PDO angepasst - die Funktion bind_result() gibt es nur für mysqli, nicht aber für PDO.
EDIT2: Quellcode für PDO angepasst - die Funktion close() heißt für PDO closeCurser(). Für manche Treiber ist es notwendig den Curser freizugeben, bevor ein anderes Prepared Statement ausgeführt werden kann.

 

[theSplit]

Hm, so gegenübergestellt gefällt mir aber der PDO Code auch besser... ich finde es etwas natürlicher wie die Werte an das Prepared Statement übergeben werden, wie auch die Angabe des Datentyps der übergeben wird.

Macht PDO eigentlich auch eine Prüfung ob der ":logname" wirklich ein String ist, wenn man zum Beispiel einen Int Wert übergibt?
Oder mal anders gefragt, wenn nicht "ss" angegeben wird bei mysqli-statement-bind_param - was vermutlich für StringWert1 und 2 steht und dahinter die Overloading-Parameter die Übergeben werden an das Prepared Statement, schmeißt mysqli dann eine Fehlermeldung oder gelten hier die Konvertierungen von PHP das ein Int zu String "gecastet" wird?

 

[Roin]

Macht PDO eigentlich auch eine Prüfung ob der ":logname" wirklich ein String ist, wenn man zum Beispiel einen Int Wert übergibt?

Da musst du den PDO-Experten fragen.

Oder mal anders gefragt, wenn nicht "ss" angegeben wird bei mysqli-statement-bind_param - was vermutlich für StringWert1 und 2 steht und dahinter die Overloading-Parameter die Übergeben werden an das Prepared Statement, schmeißt mysqli dann eine Fehlermeldung oder gelten hier die Konvertierungen von PHP das ein Int zu String "gecastet" wird?

Ja, "ss" steht für String1 String2 - Es gibt 4 "Buchstaben" zum Übergeben s=String,i=Integer,d=Double,b=BLOB.
Und die übergebenen Parameter werden in den entsprechenden Datentyp gecastet. Dabei ist darauf zu achten, dass zum Beispiel BigInt als "s" übergeben werden sollte, da andernfalls sehr große Zahlen nicht richtig gecastet werden können.
Alles genauer hier nachzulesen.

 

[Timon3]

Ich benutze mit mysqli entweder nur ganz einfache SELECT-Abfragen ohne Userinput oder Prepared Statements - und die finde ich in PDO jetzt nicht wirklich kürzer oder sowas... Ich verstehe nicht, wo du da den Vorteil siehst - außer das man am Anfang die Datenbankverbindung minimal umschreibt und dann auch andere Systeme als MySQL nutzen kann.

Kürzer ist es nicht. Muss es doch auch gar nicht - lieber länger und dafür besser lesbar. Und ich bezweifel mal, dass irgendjemand es schöner findet, Fragezeichen als Placeholder zu nehmen und dann alle Parameter als Variadics zu übergeben anstatt Named Placeholders zu haben und diese einzeln zu binden. Das schöne hier dran ist doch gerade, dass das Rebinding einzelner Parameter viel einfacher ist.

Außerdem: Gibt es irgendwas, das an mysqli besser ist als an PDO? Das Ding wirft standardmäßig nicht einmal Exceptions... der @-Operator und Fehler, die nicht geworfen werden, sind ein ziemliches No-Go.

Macht PDO eigentlich auch eine Prüfung ob der ":logname" wirklich ein String ist, wenn man zum Beispiel einen Int Wert übergibt?

PDO castet stupide nach den normalen PHP-Regeln. Wenn du eine Integer angibst und einen String übergibst, wird dieser zu einer Integer gecastet.

 

[Roin]

Gibt es irgendwas, das an mysqli besser ist als an PDO?

Nicht unbedingt. Allerdings sehe ich auch keinen richtigen Vorteil von PDO. Aber viel verändern tut sich ja auch nicht.

EDIT: Ich habe in meinem vorherigen Post den Code angepasst. das dort geschriebene PDO ist fehlerhaft gewesen.

 

[theSplit]

Naja, mysqli braucht auch gar keine Exceptions schmeißen, das läuft doch dann alles über mysql_error.log, ich will damit sagen/fragen, dort werden doch auch Queries geloggt die Fehler haben ?
Hätte dann vielleicht nur den Vorteil, PHP bricht nicht ab, selbst wenn die Queries nicht korrekt ausgeführt werden können.

Nur falls sich jemand gerade am Kopf kratzt, warum ich so töricht nachfrage, ich sitze zu wenig an Webtechnologien
Aber ich finde die antworten gerade sehr einleuchtend!

Und diese Gegenüberstellung von Roin gefällt mir mal sehr gut, lässt sich schön vergleichen. So etwas sollte man hier vielleicht öfter mal in den Raum stellen, auch zu anderen Sprachen und Merkmalen...

Aber was ich mich gerade auch frage, liegen mysqli und PDO was die Features angeht, gleich auf oder beherrscht mysqli etwas mehr oder (eher?) was vielleicht in PDO nicht oder nur schleppend integriert wird?

Und was Gamechamp noch schrieb:

Gegen mysqli selbst spricht nichts, es gibt halt Zugriff auf die Methoden der C-Bibliothek. Es abstrahiert aber fast nichts weg, das meiste wird dem Nutzer überlassen. Wenn man sich was darum baut, schön, dann ist es auch ganz gut benutzbar. Aber ohne einen Layer Fluff darum ist PDO wesentlich besser zu benutzen.

Ist die Performance hier besser bei mysqli, eben weil die C Bibliotheken angesprochen werden?
Wenn das ganze keinen Vorteil hat, würde ich spontan auch sagen, PDO.

Schon allein(?) auch deßhalb: http://php.net/manual/de/pdo.drivers.php ?
Also ein generischer Zugriff für alle gelisteten (SQL) Typen? Durch minimale Code-Änderungen (DB Connection/Verbindung) vor allen Queries? Würde gar nicht so schlecht klingen, kommt natürlich darauf an wie man die anderen Fragen beantworten würde.

 

[Roin]

Aber was ich mich gerade auch frage, liegen mysqli und PDO was die Features angeht, gleich auf oder beherrscht mysqli etwas mehr oder (eher?) was vielleicht in PDO nicht oder nur schleppend integriert wird?
[...]
Ist die Performance hier besser bei mysqli, eben weil die C Bibliotheken angesprochen werden?

mysqli ist nach diversen Quellen um bis zu 6% schneller als PDO. Mit Prepared Statements sind die Unterschiede allerdings wieder minimal, sodass man bei exsessiver Nutzung von Prepared Statements keinen Vorteil mehr mit mysqli hat.
Features scheinen weitestgehend identisch zu sein. Einzelne Funktionen von mysqli gibt es bei PDO nicht, allerdings sind diese relativ einfach zu ersetzen (ein Beispiel dabei wäre bind_result() welche nur wenige Codezeilen benötigen würde).

Als Verweis sei hier mal dieser Link in den Raum gestellt. Dort sind auch die hier genannten Punkte aufgeführt.

Ich taste mich nun auch mal an PDO heran - mal sehen, ob ich da bei meinem aktuellen Projekt viel ändern muss...

EDIT: Erneut den Code für PDO angepasst. Die close()-Funktion heißt anders.

 

[theSplit]

Ich taste mich nun auch mal an PDO heran - mal sehen, ob ich da bei meinem aktuellen Projekt viel ändern muss...

Wenn es den Rahmen hier nicht sprengt, würde ich mich auf nen Erfahrungsbericht/weiteren Vergleich freuen, vielleicht kannst du ja auch gleich noch etwas Benchmarken

 

[Timon3]

Naja, mysqli braucht auch gar keine Exceptions schmeißen, das läuft doch dann alles über mysql_error.log, ich will damit sagen/fragen, dort werden doch auch Queries geloggt die Fehler haben ?

Es nicht um Queries die Fehler haben. Es geht beispielsweise um das Aufbauen einer Verbindung. Standardmäßig muss man IMMER, wenn man unter mysqli auf Fehler überprüfen will, das ganze über die return-Values oder ähnliches machen.

Hätte dann vielleicht nur den Vorteil, PHP bricht nicht ab, selbst wenn die Queries nicht korrekt ausgeführt werden können.

Der Vorteil von Exceptions ist ganz einfach: Exceptions sind Dinge, mit denen man normalerweise nicht rechnet. Sie sind Ausnahmen, die nicht im normalen Codefluss gehandlet werden sollten, sondern separat (beispielsweise sollte man alle Exceptions loggen und dem User dann eine Fehlerseite anzeigen). Es hat einen Grund, warum alle modernen Sprachen Exceptions haben und auf diese setzen. Und auch PHP ist (auch wenn es viele anders sehen) durchaus eine moderne und ernstzunehmende Programmiersprache.

Nur falls sich jemand gerade am Kopf kratzt, warum ich so töricht nachfrage, ich sitze zu wenig an Webtechnologien

Hat wenig mit Webtechnologien zu tun als generellem Programmieren. Der normale Code kümmert sich um den normalen Programmfluss, Fehler werden separat gekennzeichnet und behandelt (z. B. durch Try-Catch-Blöcke).

Aber was ich mich gerade auch frage, liegen mysqli und PDO was die Features angeht, gleich auf oder beherrscht mysqli etwas mehr oder (eher?) was vielleicht in PDO nicht oder nur schleppend integriert wird?

mysqli unterstützt ein paar Sachen, die PDO nicht unterstützt (eben spezifische MySQL-Features, die andere Server nicht unterstützen), die Frage ist aber wie oft man so etwas braucht.

Ist die Performance hier besser bei mysqli, eben weil die C Bibliotheken angesprochen werden?

Nicht merkbar, PDO ggü. mysqli wird nie einen ernstzunehmenden Bottleneck darstellen wenn man nicht grundlegend etwas falsch macht. PDO spricht auch eine C-Bibliothek an - der Unterschied ist aber, dass die API sich stellenweise von den Bibliotheken löst, was mysqli nicht tut (siehe mysqli_real_escape_string).

Schon allein(?) auch deßhalb: http://php.net/manual/de/pdo.drivers.php ?
Also ein generischer Zugriff für alle gelisteten (SQL) Typen? Durch minimale Code-Änderungen (DB Connection/Verbindung) vor allen Queries?

Das ist etwas, das viele anfangs falsch verstehen: Mit PDO kann man NICHT eine MySQL-Query auf einem Server ausführen, der die nicht versteht! Queries müssen immer umgeschrieben werden. PDO bietet halt nur Zugriff auf verschiedenste Server über die Treiber. Wenn ich aber von MySQL zu einem inkompatiblen System wechsel, dann muss ich auch alle Queries umschreiben.

Aber gut, deshalb benutzt man ja auch meistens einen Query-Builder.

 

[theSplit]

@Gamechamp

Danke für die Erläuterungen!

Also ist PDO aber deßhalb zu bevorzugen, weil man Queries über ein Prepared Statement einrichten kann, diese Nutzen kann für eine andere DB, unter der Prämisse die Queries werden angepasst, hätte ich auch selbst drauf kommen können
Hat dann aber der Vorteil, gegenüber jetzt mysqli - das ich für diese Queries die gleiche Struktur verwenden kann und nicht alles von mysqli spezifischen Sachen, auf DB X, umschreiben müsste - Stichwort "Code reusage". Korrekt?

Das mit den Exceptions, nun ja, fast schon klar- ich dachte PDO behandelt das eventuell irgendwie noch anders oder "intelligenter" - deßhalb war ja auch eine meiner ersten Fragen ob PDO den übergebenen Datentyp überprüft oder einfach "nur" gecastet wird, weil Roin dieses "PDO::PARAM_STRING" enthalten hatte, was mir eigentlich singalisiert das ich ein Datentyp X erwarte und nichts anderes, um Type safe zu sein - was ja bei PHP oder auch Python, ich gebs zu, nicht immer der logische Fall ist.

Also ist PDO doch auf jeden Fall ein ganz guter Tip. Und wäre (eventuell) einer reinem mysqli Nutzung gegenüber zu favorisieren... aber klar, wenn es mySQL spezifisiche Sachen gibt - die PDO so nicht beherrscht, muß man das halt berücksichtigen und vorher vergleichen.

 

[Roin]

deshalb benutzt man ja auch meistens einen Query-Builder.

Da gibt es bereits fertige Sachen?
Ich habe mir bisher immer so die nötigsten Sachen selber geschrieben, um nur noch zwei oder drei Variablen mit Werten übergeben zu müssen und direkt alles fertig verarbeitet zurückkriege. Allerdings möchte ich mich bei einer Überarbeitung meines aktuellen Projekts davon lösen, da ich dabei ziemlich viel Unfug gemacht habe und somit häufig die Funktionen nicht nutzen konnte. Meistens habe ich diese anstelle der Prepared Statements alles zusammensetzen lassen. Ich habe in meinem Projekt nämlich häufig Queries, die die Länge dieses Posts deutlich überschreiten.

 

[Timon3]

Vorab: Gerne, freut mich immer wenn ich etwas Wissen teilen kann

Also ist PDO aber deßhalb zu bevorzugen, weil man Queries über ein Prepared Statement einrichten kann, diese Nutzen kann für eine andere DB, unter der Prämisse die Queries werden angepasst, hätte ich auch selbst drauf kommen können
Hat dann aber der Vorteil, gegenüber jetzt mysqli - das ich für diese Queries die gleiche Struktur verwenden kann und nicht alles von mysqli spezifischen Sachen, auf DB X, umschreiben müsste - Stichwort "Code reusage". Korrekt?

So könnte man es sagen. Die Queries selbst klappen nicht, die musst du umschreiben, aber alles draußen herum kannst du lassen. Und wenn du einen Query Builder benutzt, deine Queries also automatisch generieren lässt, dann musst du gar nichts machen

Das mit den Exceptions, nun ja, fast schon klar- ich dachte PDO behandelt das eventuell irgendwie noch anders oder "intelligenter" - deßhalb war ja auch eine meiner ersten Fragen ob PDO den übergebenen Datentyp überprüft oder einfach "nur" gecastet wird, weil Roin dieses "PDO::PARAM_STRING" enthalten hatte, was mir eigentlich singalisiert das ich ein Datentyp X erwarte und nichts anderes, um Type safe zu sein - was ja bei PHP oder auch Python, ich gebs zu, nicht immer der logische Fall ist.

Nee, PDO benutzt normale Exceptions. Ist halt schon ein riesiger Vorteil ggü. mysqli. Für die Bound Parameters muss man übrigens nicht noch den Parameter-Typ angeben - mach ich normalerweise auch nicht, weil ich vorher die Parameter validiere (sei es da ich sie selbst caste oder da die eh per typisiertem Parameter übergeben werden).

Also ist PDO doch auf jeden Fall ein ganz guter Tip. Und wäre (eventuell) einer reinem mysqli Nutzung gegenüber zu favorisieren... aber klar, wenn es mySQL spezifisiche Sachen gibt - die PDO so nicht beherrscht, muß man das halt berücksichtigen und vorher vergleichen.

Genau, das fasst es eigentlich ganz gut zusammen. Ich habe selbst noch nie den Fall erlebt, dass eines der erweiterten Features gebraucht wird, aber das weiß man normalerweise ja auch schon im Voraus.


An dieser Stelle will ich übrigens einmal erwähnen, dass es hier einen ganz guten Überblick über PDO gibt. Man sollte nur mit manchen Aussagen vorsichtig sein, da der Autor sehr überheblich ist.

 

[theSplit]

Nee, PDO benutzt normale Exceptions. Ist halt schon ein riesiger Vorteil ggü. mysqli. Für die Bound Parameters muss man übrigens nicht noch den Parameter-Typ angeben - mach ich normalerweise auch nicht, weil ich vorher die Parameter validiere (sei es da ich sie selbst caste oder da die eh per typisiertem Parameter übergeben werden).

Nur kurz hierzu, es ist bestimmt nicht verkehrt anzugeben als was oder wie der Datentyp zu behandeln wäre den man "einbauen" lassen will - außerdem hilft das einem dritten genau zu ermitteln, was für ein Datentyp erwartet wird. So würde ich jetzt denken.
Hat aber bestimmt nicht nur "kosmetische" Gründe dass man es angeben kann aber nicht muß, wie du sagst, z.B. wenn hier gecastet wird durch PHP/PDO nach Zieltyp(?).

 

[braegler]

Die Diskussion PDO vs. mysqli hab ich schon in einigen Foren mitbekommen.
Meine Ansicht:
Scheissegal welche Library man verwendet, solange man ein anständiges Wrapper-Skript hat
Für mysqli verwendet ich, wo möglich, MeekroDB. Viel einfacher geht es kaum.

Für eines meiner Projekte hatte ich mal testweise MeekroDB und einen Wrapper für PDO nacheinander getestet (avg. 2,2Mrd Q/Tag).
Ich konnte, selbst mit Microtime, keinen signifikanten Unterschied feststellen (bezogen auf die komplette Platform, also angefangen mit einfachen Selects über Joins und und und ein bunter Querschnitt).

Nachtrag von der Meekro-Homepage (mal simples Copy-Paste, also falls mir jemand einen Doktortitel dafür geben will........)

So how is MeekroDB better than PDO?
If you haven't read the page on Our Beliefs, please read that as well.

Optional static class mode
Most web apps will only ever talk to one database. This means that passing $db objects to every function of your code just adds unnecessary clutter. The simplest approach is to use static methods such as DB::query(), and that's how MeekroDB works. Still, if you need database objects, MeekroDB can do that too.
Do more with fewer lines of code
The code below escapes your parameters for safety, runs the query, and grabs the first row of results. Try doing that in one line with PDO.
$account = DB::queryFirstRow("SELECT * FROM accounts WHERE username=%s", 'Joe');


Work with list parameters easily
Using MySQL's IN keyword should not be hard. MeekroDB smooths out the syntax for you, PDO does not.
$accounts = DB::query("SELECT * FROM accounts WHERE username IN %ls", array('Joe', 'Frank'));


Simple inserts
Using MySQL's INSERT should not be more complicated than passing in an associative array. MeekroDB also simplifies many related commands, including the useful and bizarre INSERT .. ON DUPLICATE UPDATE command. PDO does none of this.
DB::insert('accounts', array('username' => 'John', 'password' => 'whatever'));

Focus on the goal, not the task
Want to do INSERT yourself rather than relying on DB::insert()? It's dead simple. I don't even want to think about how many lines you'd need to pull this off in PDO.
// Insert 2 rows at once
DB::query("INSERT INTO %b %lb VALUES %?", 'accounts',
array('username', 'password', 'last_login_timestamp'),
array(
array('Joe', 'joes_password', new DateTime('yesterday')),
array('Frank', 'franks_password', new DateTime('last Monday'))
)
);

Nested transactions
MySQL's SAVEPOINT commands lets you create nested transactions, but only if you keep track of SAVEPOINT ids yourself. MeekroDB does this for you, so you can have nested transactions with no complexity or learning curve.
DB::$nested_transactions = true;
DB::startTransaction(); // outer transaction
// .. some queries..
$depth = DB::startTransaction(); // inner transaction
echo $depth . 'transactions are currently active'; // 2

// .. some queries..
DB::commit(); // commit inner transaction
// .. some queries..
DB::commit(); // commit outer transaction

Flexible error and success handlers
Set your own custom function run on errors, or on every query that succeeds. You can easily have separate error handling behavior for the dev and live versions of your application. Want to count up all your queries and their runtime? Just add a new success handler.

 

[Timon3]

@theSplit: Ob es sinnvoll ist oder nicht ist die Frage. Normalerweise wird in meinem Code direkt klar, welchen Datentyp ich erwarte, da ich das in der Methodensignatur angebe. Aber gut, es ist eh extrem selten dass ich mal roh MySQL schreibe, ich benutze eigentlich nur noch ORMs.

@braegler: Ich hab mir die Bibliothek gerade mal angeschaut. Ich würde davon abraten, sie zu nutzen. Einerseits schreckt natürlich der Preis ab, aber das ist nicht mal das schlimmste - aber man sollte mittlerweile wirklich keine Bibliotheken mehr benutzen, die man nicht über Composer einbindet. Das macht das Updaten und das verteilen auf die Production-Server viel zu aufwendig.