Welche SQL-Funktionen nutzt Ihr so?

Dennis Wronka

Soulcollector
Ich bastel grad an einer SQL-Klasse (bitte keine Kommentare, dass es solche schon gibt wie Sand am Meer, das ist mir bereits klar ;) ) welche die Funktionen verschiedener Datenbank-Systeme vereinen soll um die Portierung eines Projekts von einem DBMS zu einem anderen zu vereinfachen. Zur Zeit arbeite ich an den Funktionen fuer MySQL und PostgreSQL. Auf der Arbeit hab ich auch einen MSSQL-Server zur Verfuegung, sodass ich dort die entsprechenden Funktionen dafuer schreiben kann.

Nun will ich keine Funktionen implementieren die kein Mensch benoetigt aber es soll schon alles drin sein was man so braucht. Daher dieser Thread.
Bisher hab ich folgende Funktionen:
  • query()
  • fetch_assoc()
  • fetch_row()
  • fetch_array() (obwoh ich da ueberlege ob man die ueberhaupt braucht, denn wann braucht man schonmal sowohl einen numerischen als auch alphabetischen Index?)
  • fetch_object()
  • num_rows()
  • escape_string()
  • affected_rows()
  • free_result()
  • error()
Zusaetzlich hab ich noch die folgenden Funktionen eingefuehrt:
  • getresultset()
  • setresultset()
Der Grund fuer diese Funktionen ist folgender: Das Resultset einer Query wird innerhalb der Klasse festgehalten.
Bei Konstrukten wie diesem
PHP:
$forum_posts=mysql_query("select * from `forum_posts` order by `id`");
while ($forum_post=mysql_fetch_assoc($forum_posts))
{
 $users=mysql_query("select * from `users` where `id`='".$forum_post['userid']."'");
 $user=mysql_fetch_assoc($users);
 //Ausgabe
}
mit der Klasse umsetzen will wird innerhalb der Schleife ja das Resultset ueberschrieben.
PHP:
$sql->query("select * from `forum_posts` order by `id`");
while ($forum_post=$sql->fetch_assoc())
{
 $sql->query("select * from `users` where `id`='".$forum_post['userid']."'");
 $user=$sql->fetch_assoc();
 //Ausgabe
}
Dies fuehrt dann zum Fehler bei der Schleifenverarbeitung.
Dafuer dann halt die Funktionen getresultset() und setresultset().
Damit kann innerhalb der Schleife das Resultset zwischengespeichert und wiederhergestellt werden.
PHP:
$sql->query("select * from `forum_posts` order by `id`");
while ($forum_post=$sql->fetch_assoc())
{
 $forum_posts=$sql->getresultset();
 $sql->query("select * from `users` where `id`='".$forum_post['userid']."'");
 $user=$sql->fetch_assoc();
 //Ausgabe
 $sql->setresultset($forum_posts);
}
Dadurch laeuft die Schleife genauso ab wie im ersten Beispiel.
Ich weiss, sowas laesst sich auch mit JOIN in einer Abfrage machen, aber nicht jeder ist so sehr mit SQL vertraut, dass er mit JOIN arbeitet. Daher eben diese Moeglichkeit des Imports und Exports des Resultsets.

Nun aber zu meiner eigentlichen Frage:
Was fuer Funktionen benoetigt Ihr sonst so in Euren Scripts? Zusaetzlich zu den oben bereits aufgefuehrten.
Ich denke die wichtigsten Funktionen hab ich bereits abgedeckt, aber ich will nicht ausschliessen, dass ich irgendwas vergessen habe.
 
Die letzte InsertId wär noch ganz gut! Bei MySQL mysql_insert_id(), den Error, den die DB zurückgibt, wär noch ganz gut denke ich! Und was noch ganz gut ist, nen SELECT FOUND_ROWS() Query direkt absetzen zu können. Ist für SQL_CALC_FOUND_ROWS Querys interessant.

PS: Weiß jetzt nicht so umbedingt, ob das auf PG oder ähnliches portierbar ist!
 
Also ich benutze öfters noch insert_id.

/edit:
Schon doof wenn man auf Antworten klickt und dann einfach erstmal 5 Minuten afk ist ;-)
 
Hallo,

du abstrahierst bislang nur die reinen Zugriffsfunktionen, die natürlich einen gewissen Teil an Portabilität bieten, aber die Query-Sachen an sich lässt du ein wenig außer Acht.

Ich weiß nicht ob es in dein Konzept passt (da eine echte DB-Abstraktion ohnehin einen Query-Parser enthalten müsste), aber vielleicht guckst du ja, ob du es schaffst gewisse Dinge nachzubilden, spontan fällt mir da der "LIMIT"-Befehl in MySQL ein, den es so im SQL Standard nicht gibt.

Außerdem wäre eine Unterstützung für Prepared Statements ganz nett.

Hmm, genug gefaselt, hoffe du kannst damit was anfangen.

Gruß,
- Robin
 
insert_id():
Ueber insert_id() koennte ich nachdenken wenn ich einen Query-Builder einbaue. Das Problem ist naemlich, dass es diese Funktion weder bei PostgreSQL noch bei MSSQL gibt.
Bei PostgreSQL gibt es zwar eine aehnliche Funktion, nur ist diese wohl nicht mehr aktuell.
Bei mysql_insert_id() gibt es ja auch noch das Problem, dass zwischen dem Insert und dem Aufruf der Funktion durchaus noch was anderes eingetragen worden sein kann.

Das Problem was ich zur Zeit noch bei dem Query-Builder hab ist folgendes: Ich will da nicht nur simple Queries ermoeglichen sondern auch komplexe. Daher hab ich bisher noch keinen Ansatz wie ich da rangehen soll. Naja, hab ja auch erst gestern mit der Klasse angefangen.

LIMIT:
LIMIT gibt es, wenn ich das richtig gesehen hab, auch in PostgreSQL, nur bei MSSQL sieht es da eben schlecht aus. Dort gibt es zwar TOP, nur kann man dort wohl nicht wie bei LIMIT ein Offset angeben.

SELECT FOUND_ROWS():
Entspricht SELECT FOUND_ROWS() nicht eigentlich der Funktion num_rows()?

Error-Funktion:
Die Funktion error() gibt es bereits. Steht auch schon oben in der Liste.

Prepared Statements:
Uff, jetzt wirst Du aber heftig. Damit hab ich mich noch garnicht befasst. Ich weiss nichtmal ob diese in allen 3 unterstuetzten DBMS zur Verfuegung stehen.
 
Hi,

naja, das Ding ist, es gibt sogar innerhalb gewisser Datenbanksysteme Unterschiede. Bestes Beispiel ist MySQL mit seinen unterschiedlichen Storage Engines. Der Unterschied zwischen InnoDB und MyISAM ist gewaltig und es gibt aber für beide ihre Berechtigung (Off-Topic: Sehr zu empfehlen ist das Buch "High Performance MySQL").

Der Trick ist, eben sowas soweit wie möglich zu emulieren, wenn man denn wirklich Portabilität bieten will. Oder man beschränkt sich dann eben auf die reinen Zugriffsfunktionen. PDO machts nichts anders, wenn Prepared Statements nicht unterstützt werden vom DB-Treiber werden sie emuliert. Ist ja auch kein Problem das über saubere Interfaces zu implementieren.

Ach so, was mir noch eingefallen ist, ich benutze sehr häufig Transaktionen, ein Support dafür wäre auch nicht schlecht.

Es mag aber auch sein, dass ich nicht zu der Klientel gehöre, für die du deine Klasse machst, insofern solltest du das natürlich unter Vorbehalt sehen.

Zum Thema last_insert_id: Rate ich von ab, ist nicht atomar und nicht Race Condition sicher, hat schon die eine oder andere Lücke verursacht.

Die Funktion error() gibt es vielleicht, aber hast du vielleicht schon mal über Exceptions nachgedacht? (ich weiß nicht ob es eine PHP5-only Klasse wird)

Off-Topic: gerade aus einem vierstündigen Gespräch mit Taiwan gekommen ... und jetzt ein Post von dir ... die Chinesen verfolgen mich! Ich renn besser weg :suspekt:
 
Sir Robin hat gesagt.:
Ach so, was mir noch eingefallen ist, ich benutze sehr häufig Transaktionen, ein Support dafür wäre auch nicht schlecht.
Uff, Du kommst echt mit krassen Sachen um die Ecke. Naja, werd mich jetzt wirklich mal was mehr mit SQL beschaeftigen muessen. Also mit Sachen die ueber simple Queries hinausgehen. Gut, dass ich in diversen Linux-Magazinen schon gut Literatur dazu hab. Und ansonsten gibt's ja auch das Internet.

Sir Robin hat gesagt.:
Die Funktion error() gibt es vielleicht, aber hast du vielleicht schon mal über Exceptions nachgedacht? (ich weiß nicht ob es eine PHP5-only Klasse wird)
Nachgedacht schon. Bei jeder meiner Klassen. Nur da ich bisher alle Klassen auch auf PHP4 zurueckportiert hab (entwickelt wird aber grundsaetzlich fuer PHP5) hab ich davon bisher abgesehen.

Sir Robin hat gesagt.:
Off-Topic: gerade aus einem vierstündigen Gespräch mit Taiwan gekommen ... und jetzt ein Post von dir ... die Chinesen verfolgen mich! Ich renn besser weg :suspekt:
... when danger reared it's ugly head, he bravely turned his tail and fled ...
 
Hi,

das ist im Grunde ein interessantes Thema, weil ich sehr davon ausgehe, das von den vorhandenen Möglichkeiten gerade mal (meine Schätzung) 30% genutzt werden. Ich habe mir z.B. über das Wochenende eine ganz neue Welt erschlossen bzgl. Funktionen in SQL / MySQL.

Ansonsten natürlich das übliche. Was hier im Forum und im MySQL-Forum eh schon enthalten ist.

Interessant finde ich Bspw. die Vergleichsoperationen im SELECT-Bereich. Allerdings ist mir noch nicht ganz klar, wie sich das auf das Ergebnis auswirkt, was ich noch genauer testen will.
 
Dennis Wronka hat gesagt.:
Uff, Du kommst echt mit krassen Sachen um die Ecke. Naja, werd mich jetzt wirklich mal was mehr mit SQL beschaeftigen muessen. Also mit Sachen die ueber simple Queries hinausgehen. Gut, dass ich in diversen Linux-Magazinen schon gut Literatur dazu hab. Und ansonsten gibt's ja auch das Internet.

Nun ja, ich programmiere halt nur mehr selten kleinere Dinge, sondern meist schon an größeren Projekten sodass Datenintegrität und Konsistenz sehr wichtig sind. Und wenn ich von einer DB-Klasse lese die, die Portabilität erleichtern soll, dann frage ich mich natürlich wozu das einer braucht? Für seine kleine Gästebuchanwendung wohl eher weniger, sondern eher für eine ernsthaftere Anwendung. Und beim Stichwort ernsthaftere Anwendungen fallen mir eben jene Begriffe ein :) Vielleicht ist mein Gedankengang ja auch nur abstrus, aber ich dachte es hilft dir vielleicht.
 
Zurück