(My)SQL Abstraktionsklasse?

[c4]

Moin,

bin ein wenig verwirrt und nicht auf dem Laufenden. Früher hatte ich mal ADODB genutzt (5 Jahre her?), um SQL-Anfragen abzuschicken. Was nutzt man heute? Bin über MDB2 gestolpert. Ist das toll? :)
Wäre eigentlich froh, wenn's was ohne PEAR im Hintergrund ist.

Wo gibt's evtl. eine Übersicht über solche Klassen?
Nach "sql class php" zu suchen bringt's nicht wirklich...

Und gibt's vllt. was, was man nicht immer instanzieren muss? Wird ja auch irgendwann lästig in jeder Methode eine MDB2-Instanz in die Welt zu setzen. Obwohl es das wohl eher nicht gibt. Zumindest nicht sauber programmiert.

Dank,
Carsten

[xabbuh]

Vielleicht PDO?

[c4]

Begeisterungsstürme konnte PDO noch nicht auslösen, dafür wird's aber nativ unterstützt, das ist gut.

Ich probier's mal, danke!

[feuervogel]

also ich finde mdb2 klasse, hat doch so weiß ich weiß auch ne factory-methode und es gibt ein singleton davon, so dass du nicht in jeder methode eine neue instanz erzeugst :-)

[c4]

Keine neue DB-Verbindung, das stimmt. Aber ich muss jedes Mal auf's Neue new MDB2irgendwas() machen. Ein ungeheuerlicher Aufwand. :)

[c4]

Eine Übersicht / Vergleichstabelle solcher Klassen kennt aber nicht zufällig wer?

Damals hieß es auch, dass man z. B. mit ADODB 70% (o.ä.) schneller dabei ist. Gibt sicher einige Unterschiede, könnte Interesse dafür anmelden.

Carsten

[meikel (†)]

Zitat von c4

Eine Übersicht / Vergleichstabelle solcher Klassen kennt aber nicht zufällig wer?

Ich nicht, aber...

Damals hieß es auch, dass man z. B. mit ADODB 70% (o.ä.) schneller dabei ist.

Das halte ich für ein Gerücht. Ich halte auch nix von Abstraktionsklassen, die mit einem Sack voll Billig- bis Sauteuer-DBMS zu hantieren vorgeben.

Wer sich mal etwas genauer mit den Möglich- und Widrigkeiten verschiedener DBMS beschäftigt hat, wird logischerweise zu dem Ergebnis kommen, daß eine egal wie auch immer heißende Abstraktionsklasse bestenfalls für Simpel-SQL geeignet ist, weil zB. MS SQL ganz andere Möglichkeiten bietet als Oracle, Postgres, MySQL, SQLite. Die Betonung liegt hier auf *andere*. Es erfordert in vielen Fällen ein neues bzw. ganz anderes Konzept, wenn man die DB Engine wechselt. "Dufte Tools" oder "mächtige Klassen", die vorgeben, sie kämen mit allem klar, verbraten in erster Linie nur Rechenzeit.

Meine kleine feine und *etwas* PEAR kompatible (Machart und Methodenbezeichner) MySQL Klasse (jo, ich arme Sau kann mir im Netz weder Oracle noch MS SQL leisten) ist mehr als doppelt so schnell als das Vorbild.

Selbst wenn es DB2-, Oracle- oder MS SQL-Server für Lau gäbe, würde ich trotzdem das Konzept an das DBMS anpassen. Ja, so faul bin ich nun mal... <g>

[c4]

Ja, recht hast Du meikel.
Da ich eh vor hatte eine Klasse zu schreiben, die den DB-Kram erledigt (mit was auch immer), bin ich in der Zukunft auch flexibel. Einfach Klasse (mit anderer DB-Anbindung) austauschen und Ruhe ist.

Hab mich überzeugt. Faulheit ruleZ[sic]!