Tach!
Projekte, die nicht "mehreren verschiedenen Datenbankmaschinen gleichzeitig arbeiten (müssen)".
das ist aber heutzutage bei jedem kommerziellen Projekt zu erwarten/befürchten.
Und das heißt nun, dass man das bei jedem Projekt, egal ob ein kommerzieller Hintergrund oder welcher Anwendungsfall auch immer das ist, berücksichtigen muss? Das glaube ich ja wohl kaum.
Hier möchte ich Gunnars ewig zitierte fortschreitende Erweiterungen mal auf die Betriebssystem- und Datenbankwelt übertragen.
Datenquellen und -senken sind heutzutage nicht nur klassische SQL-Datenbanken. Es gibt auch anderen Schnittstellen, die zu bedienen sind, und bei denen PDO nicht weiterhilft.
Es ist z. B. sehr wahrscheinlich, dass ein eShop auf der eigenen Seite mit MySQL arbeitet, aber bei diversen Lieferanten direkte Datenbankzugänge erhält, die z. B. auf M$SQL, DB2, Informix, Postgre (SQL), oder anderen basieren.
SOAP und REST sind auch Kandidaten bei Shops.
Jedenfalls "wev-skills ein bisschen zu verbessern" klingt aber nicht nach einer Shop-Anwendung und dass es unbedingt was Datenbankübergreifendes werden muss. Dass es Anwendungsfälle für unterschiedliche Datenbanktypen oder die Migration von einem auf ein anderes System gibt, heißt noch lange nicht, dass man das für jedes Projekt berücksichtigen muss. Falls sich Anforderungen in der Zukunft ändern, dann ist nicht so sehr ausschlaggebend, ob man PDO oder was anderes verwendet hat, sondern ob das Projekt so modular aufgebaut ist, dass man problemlos zum Beispiel den Datenbank-Teil austauschen kann.
Leider arbeiten die PHP Data Objects noch extrem kompliziert. Man könnte das alles viel einfacher und transparenter regeln, wenn man sich nicht so sehr an die PHP-Typenfreiheit klammern würde.
Bitte begründe die sehr starke Wortwahl "extrem kompliziert".
dedlfix.