nicht angemeldet
PDO / mysqli
Hallo,
immer wieder lese ich hier im Forum man sollte lieber auf PDO als auf mysqli setzten. Meine Frage ist, kann ich beide miteinander mischen oder muss ich alle Scripte sofort umstellen?
Damit meine ich, alte Scripte erst einmal auf mysqli lassen und die neuen auf PDO aufbauen?
-
Tach!
immer wieder lese ich hier im Forum man sollte lieber auf PDO als auf mysqli setzten.
"Soll" nicht. Aber es arbeitet sich angenehmer mit PDO als mit mysqli, besonders was das Handling mit den Prepared Statements angeht. Das umständliche Binden mit den Referenzen auf Variablen kann man zum Beispiel weglassen. Siehe Beispiele 2, 3 und 5.
Solange man keine speziellen Features von MySQL verwendet, die nur mit der mysqli-API auszuführen gehen, ist PDO eine gute Alternative.
Meine Frage ist, kann ich beide miteinander mischen oder muss ich alle Scripte sofort umstellen?
Miteinander mischen nicht, aber beides gleichzeitig für getrennte Vorgänge geht problemlos.
Damit meine ich, alte Scripte erst einmal auf mysqli lassen und die neuen auf PDO aufbauen?
Das geht.
dedlfix.
-
es arbeitet sich angenehmer mit PDO als mit mysqli, besonders was das Handling mit den Prepared Statements angeht.
Stimmt, ist aber der mit Abstand geringste Grund.
Wichtiger dürfte sein, dass man PDO sehr schnell den Datenbankserver wechseln kann. Was nötig sein könnte, wenn z.B. ein gewisser Trump verfügt, dass alle in den USA hergestellten Datenbankserver (MySQL gehört zu Oracle) einen Zugang für die NSA und andere bieten müssen* oder in Norwegen wieder rote Fahnen mit weißem Kreis und irgendwas schwarzem drin hängen.
*) Wer glaubt, sowas gäbe es nicht, der schaue sich das bundesdeutsche Recht an, wonach die ISPs und Telefonkonzerne den Geheimdiensten einen unbeobachteten Zugang anbieten müssen ("Artikel 10-Gesetz").
Wer es immer noch nicht glaubt, der schaue in das manual von useradd
-l, --no-log-init Do not add the user to the lastlog and faillog databases.Das dient genau dazu und wurde explizit eingeführt damit die ISPs und Telefonkonzerne den Geheimdiensten einen unbeobachteten Zugang anbieten können und wird definitiv auch genau dafür genutzt!
-
Tach!
es arbeitet sich angenehmer mit PDO als mit mysqli, besonders was das Handling mit den Prepared Statements angeht.
Stimmt, ist aber der mit Abstand geringste Grund.
Wichtiger dürfte sein, dass man PDO sehr schnell den Datenbankserver wechseln kann.
Das halte ich wiederum für den geringsten Grund. Wann wechselt man mal eben für seine ganze Anwendung das Datenbanksystem? Dem "sehr schnell" steht entgegen, dass SQL nicht gleich SQL ist, und man die diversen Dialekte beachten muss.
dedlfix.
-
Dem "sehr schnell" steht entgegen, dass SQL nicht gleich SQL ist, und man die diversen Dialekte beachten muss.
- Dann stell mal etwas wie ein CMS mit und ohne PDO vom mysql auf sqlite um...
-
Tach!
Dem "sehr schnell" steht entgegen, dass SQL nicht gleich SQL ist, und man die diversen Dialekte beachten muss.
- Dann stell mal etwas wie ein CMS mit und ohne PDO vom mysql auf sqlite um...
Ja, und? Du meinst, es reicht einfach den Connection-String zu tauschen und fertig ist? Da irrst du dich aber. Wenn man dem Projekt die wichtigste Grundlage austauscht, braucht es schon etwas mehr Aufwand für das Prüfen und Anpassen der Statements.
Die Frage ist für mich aber nicht, wieviel Aufwand man hat, sondern wie wahrscheinlich es ist, dass man das je wollen wird. Kaum bis gar nicht.
Natürlich hilft es, wenn man dann doch die Entscheidung gefällt hat, die Funktionen nicht weiter anfassen zu müssen. Doch wenn man es gleich richtig machen möchte, nimmt man eine Abstraktionsschicht, bei der man gar nicht mehr mit SQL in Berührung kommt, stattdessen nur Objekte hin und her reicht, und die sich selbständig um das Ausbügeln aller Unterschiede kümmert.
dedlfix.
-
Doch wenn man es gleich richtig machen möchte, nimmt man eine Abstraktionsschicht, bei der man gar nicht mehr mit SQL in Berührung kommt,
Die muss aber auch jemand geschrieben haben, der die Entscheidung zwischen nativen libs für mysql, sqlite[3], ... einerseits und PDO andererseits treffen musste. Das Problem wird also nur verschoben, muss aber gelöst werden.
"Abstraktionsschicht"
Doch wenn man es gleich richtig machen möchte
Doch wenn man es gleich richtig langsam machen möchte, dann greift man auf diese "Abstraktionsschicht" über drei weitere zu, die wieder drei weitere "Abstraktionsschichten" bemühen.
-
Was richtig "Spaß" macht wenn man dafür "gut getestete Frameworks mit breiter Nutzerbasis" und unterschiedlichen Updatezyklen (und Methoden!) benutzt.
-
Was noch mehr "Spaß" macht wenn die Hersteller der "gut getestete Frameworks mit breiter Nutzerbasis" im Fehlerfall auf den anderen zeigen statt das Problem zu lösen.
Das Resultat ist dann etwas wie der Berliner Flughafen, der mit ganz modernen Methoden ja schon länger umgebaut und nachgerüstet wird als für die Errichtung mancher ägyptischer Pyramide mit Seilen, Tragen und Hebeln benötigt wurde…
-
Tach!
Doch wenn man es gleich richtig machen möchte, nimmt man eine Abstraktionsschicht, bei der man gar nicht mehr mit SQL in Berührung kommt,
Die muss aber auch jemand geschrieben haben, der die Entscheidung zwischen nativen libs für mysql, sqlite[3], ... einerseits und PDO andererseits treffen musste.
Nö, die kann auch jemand geschrieben haben, der einfach nur einen generellen Bedarf für deren Existenz sah. Wenn es jedoch um eine Entscheidung für ein eigenes Projekt geht, würde ich nicht noch dazu eine solche Software schreiben wollen, sondern eine vorhandene einsetzen, wenn denn darin für das Projekt ein Vorteil zu sehen ist.
dedlfix.
-
Irgendwie weichst Du in extremen Sprüngen vom eigentlichen Inhalt der Unterhaltung ab.
Auch für die von Dir nunmehr in die Diskussion eingeführte "vorhandene Software" gilt das von mir geschriebene:
Die muss aber auch jemand geschrieben haben, der die Entscheidung zwischen nativen libs für mysql, sqlite[3], ... einerseits und PDO andererseits treffen musste.
-
Tach!
Irgendwie weichst Du in extremen Sprüngen vom eigentlichen Inhalt der Unterhaltung ab.
Auch für die von Dir nunmehr in die Diskussion eingeführte "vorhandene Software" gilt das von mir geschriebene:
Die muss aber auch jemand geschrieben haben, der die Entscheidung zwischen nativen libs für mysql, sqlite[3], ... einerseits und PDO andererseits treffen musste.
Vielleicht hab ich auch etwas anderes in dieser Aussage gelesen als du gemeint hast, weil du in meiner vorhergehenden Aussage was anderes gelesen hast. Für mich war das jedenfalls eine Fortsetzung zu jener Aussage. Die Abstraktionsschicht, die ich meinte, war sowas wie ein fertiges ORM eines Drittherstellers.
dedlfix.
-
Die Abstraktionsschicht, die ich meinte, war sowas wie ein fertiges ORM eines Drittherstellers.
Unter ORM finde ich:
Nachteil dieses dem OOP-Paradigma entgegenkommenden Ansatzes ist das Nicht-Ausnutzen der Stärken und Fähigkeiten einer relationalen Datenbank, was sich in nicht optimaler Leistung niederschlägt.
(Man beachte die betont neutrale und stark zurück haltende Ausdrucksweise!)
Und immer noch muss auch der ORM-Hersteller die diskussionsgegenständliche Entscheidung zwischen nativen Datenbankfunktionen (oder Objekten) und PDO getroffen haben. Das gilt auch dann wenn Du - unter Erkaufen durch teilweise horrende Leistungseinbußen - durch das ORM von dieser Entscheidung befreit bist. Und, bitte, erzähle mir nicht, dass sich ein ORM einfach austauschen lässt.
-
Tach!
Die Abstraktionsschicht, die ich meinte, war sowas wie ein fertiges ORM eines Drittherstellers.
Unter ORM finde ich:
Nachteil dieses dem OOP-Paradigma entgegenkommenden Ansatzes ist das Nicht-Ausnutzen der Stärken und Fähigkeiten einer relationalen Datenbank, was sich in nicht optimaler Leistung niederschlägt.
Ja natürlich. Aber der Nachteil ist vielen Projekten keiner mehr, weil in ihnen die Vorteile dieser Vorgehensweise deutlich schwerer wiegen.
Und immer noch muss auch der ORM-Hersteller die diskussionsgegenständliche Entscheidung zwischen nativen Datenbankfunktionen (oder Objekten) und PDO getroffen haben. Das gilt auch dann wenn Du - unter Erkaufen durch teilweise horrende Leistungseinbußen - durch das ORM von dieser Entscheidung befreit bist. Und, bitte, erzähle mir nicht, dass sich ein ORM einfach austauschen lässt.
Anfangs ging es dir lediglich um die Austauschbarkeit des DBMS. Wenn du nun auch noch die Austauschbarkeit von Abstraktionslayern wie einem ORMs betrachten möchtest, darfst du auch die Austauschbarkeit von Low-Level-Abstraktionen wie PDO nicht unberücksichtigt lassen.
dedlfix.
-
-
-
-
-
-
-
Wichtiger dürfte sein, dass man PDO sehr schnell den Datenbankserver wechseln kann.
Die meinst wohl die Engine. Und da ist PDO tatsächlich etwas fortschrittlicher weil er auf ein Modell mit austauschbaren Layern aufsetzt. Immerhin hält sich PDO auch schon paar Jahre und wird weiterentwickelt.
--
Young, Gifted And Black, danke Bob And Marcia (wird dieses Jahr 70!)
-
-