@Martin: Wenn wir schon in der main distribution mit ext-interbase nicht mehr enthalten sind, dann können wir dort auch aufhören, wie seit fast 20 Jahren unter dem Namen Interbase zu segeln. Gerade bei Firebird 3 und 4 sind reihenweise Features drin, die es bei Interbase nicht gibt. In der PHP-Mailingliste deutete einer zwar an, dass wir später nicht mehr in die main distribution reinkommen, wenn wir jetzt einen Firebird-Only-Treiber machen, aber das will ich erst mal sehen, bzw ist auch egal. Das hätten sie sich vorher überlegen können, dass wir dann nicht mehr an ihre Wünsche/Vorgaben gebunden sind, wenn sie uns rauswerfen. In Kürze gibt es dann nämlich keinen interbase-Treiber mehr, da Embarcadero sich mW überhaupt nicht drum kümmert. Die Umbenennung sollte kein Problem sein, es gab vor Jahren schon mal Vorschläge im PHP-Umfeld, den ext-interbase auch unter ext-firebird anzubieten bzw die Funktionen auch. Finde das natürlich nicht mehr.
@bfuerchau: Der Imageverlust setzt sich so zusammen: Bisher hat das PHP-Team signalisiert, dass sie die ext-interbase für so wichtig und qualitativ gut genug einstuften, dass sie die in der main distribution mit verwalteten und auslieferten. Das war ein Qualitätssiegel und wird gerade revidiert.
Auch wenn Du zufrieden mit .Net bist, finde ich es keine gute Idee, etwas so low-level wie einen Datenbanktreiber in Zwiebelschichten zu verpacken, auch die Verwendung von COM-Objekten macht die Sache nur komplexer. PHP implementert in C, soweit ich weiß, evtl C++, Geschmackssache, jedenfalls ist das die Ausgangsbasis. Wenn man 10 Mio Sätze irgendwo rausholen muss oder parallel mit zig Connections oder Transaktionen auf der DB rumorgelt, will man keinen Wrapper irgendwo.
Mit dem ODBC-Treiber hat das alles gar nichts zu tun, das war sicher ein Missverständnis.
Bzgl neue und akzeptierte Treiber: Auch pdo-Firebird, der von Dir und den PHP-Leuten wiederholt als Alternative ins Spiel gebracht wird, ist keine. Es gibt keinen Ersatz für einen native Treiber, es sei denn, man braucht nur eine Teilmenge der Features. Man kann dort keine Einschränkung auf den kleinsten gemeinsamen Nenner hinnehmen, die dadurch entsteht, dass ein API mehrere Datenbanksysteme abdecken soll. Das ist gerade der Sinn von native Treibern, dass sie den vollen Funktionsumfang eines DBMS zugänglich machen, ohne Rücksicht darauf, ob es das Feature in anderen Systemen auch gibt. Ein schönes Beispiel findet sich im native Firebird-Treiber für Python. Firebird unterstützt im Gegensatz zu einigen anderen DBs mehrfache unabhängige Transaktionen pro Connection: https://fdb.readthedocs.io/en/v2.0/usag ... ansactions. Die Designer des Python DB-APIs kannten dieses Konzept offensichtlich nicht. Entsprechend musste der Entwickler des native Firebird-Treibers an einigen Stellen mit workarounds arbeiten bzw die Vorgaben des APIs sogar verletzen. Sowas nervt bei einem native Treiber einfach nur. Einige Anwender brauchen den Werkzeugkasten 100% und den soll es genau so geben. Mit der Zeit finden sich dann mehr Leute, die den Nutzen erkennen. Aber dafür muss er überhaupt mal angeboten werden, und eben nicht "wir wissen schon, was gut für euch ist, den Rest braucht ihr eh nicht". Speziell, wenn das von Leuten kommt, die keine Datenbankprofis sind und obendrein von der konkreten Datenbank keine Ahnung haben.
Auf der PHP-pdo-Seite https://www.php.net/manual/de/book.pdo.php ist mit 100 "likes" der mit Abstand am höchsten bewertete Userkommentar
Natürlich nicht. Wie soll die DB ein prepare machen, wenn die Tabelle unbekannt ist?Won't work:
$sth = $dbh->prepare('SELECT name, colour, calories FROM ? WHERE calories < ?');
Viele Kern-Entwickler der Web- und Skriptsprachenszene haben nach wie vor so gut wie keine Ahnung von Datenbanken. Entsprechend nutzen die meisten ihrer Anwender daher Datenbanken auf MySQL-Niveau und haben am liebsten gar nichts direkt mit der Datenbank zu tun, sind schon froh, wenn sie insert, update und delete hinbekommen. Von window functions haben die noch nie gehört, gibts bei MySQL auch nicht, oder lass die mal gezielt einen Index setzen, weil eine Abfrage lahmt. Aus der Ausgangssituation ergaben sich dann so krude, aber etablierte Konzepte wie MVC und ORM, die helfen, wenn man keine Ahnung von Datenbanken hat, auch nichts damit zu tun haben will, sie aber dynamisch nutzen muss. Wasch mir den Pelz, aber mach mich nicht nass. Ich halte das für eine Fehlentwicklung. Die Power und Eleganz, die man bekommt, wenn man die volle Leistungsfähigkeit eines DBMS wie Firebird nutzen kann und SQL die erste Fremdsprache ist, ist in einer anderen Liga. Ich habe das zu oft gesehen, in Shopsystemen, in CMS, in CRM-Systemen wie OroCRM/Symfony, das ist überall der selbe Käse.
Grüße, Volker