nicht angemeldet
PDO vs MySQLi
TS
Rolf BHey SelfHTML-Community,
ich bin derzeit dabei, meine webdev-skills ein bisschen zu verbessern, indem ich mich etwas mehr mit Query-Security bzw. SQLInjection-Protection beschäftige. Nun habe ich über Google 2 Möglichkeiten gefunden: PDO und MySQLi.
Welche davon würdet ihr bevorzugen/empfehlen? Warum?
Vielen Dank im vorraus,
HD 😀
-
Tach!
ich bin derzeit dabei, meine webdev-skills ein bisschen zu verbessern, indem ich mich etwas mehr mit Query-Security bzw. SQLInjection-Protection beschäftige.
Die eigentliche Thematik ist, Querys syntaktisch korrekt zu formulieren. Denn auch ohne Injection vorzuhaben, erzeugen bestimmte Werten, die nicht richtig an der jeweiligen Stelle eingetragen werden, Syntaxfehler und damit eine Fehlfunktion im Programm. Dass man diese Fehlfunktionen gezielt ausnutzen kann, um ungewünschte Dinge auszuführen ist da quasi nur ein Nebenprodukt. Sicheres Programmieren ist nicht nur eine Frage der Sicherheit, sondern der, ein korrekt laufendes Programm zu erstellen.
Das ist eine generelle Problematik, die sich nicht auf SQL beschränkt, sondern immer beachtet werden muss, wenn Code und Daten zusammengeführt werden müssen. Siehe Kontextwechsel.
Nun habe ich über Google 2 Möglichkeiten gefunden: PDO und MySQLi.
Welche davon würdet ihr bevorzugen/empfehlen? Warum?
mysqli empfehle ich nur noch, wenn spezielle Fähigkeiten dieser API benötigt werden, also üblicherweise nicht. PDO ist verwenderfreundlicher, besonders was die Übergabe von Werten an Prepared Statements anbelangt.
dedlfix.
-
Die offensichtlichste Einschränkung ist: MySQLi kann nur MySQL. Das reicht mir nicht. Eine Umstellung zieht meist schon die Anpassung der SQL-Statements nach sich, da will ich nicht auch noch den Wrapper anpassen müssen.
-
Tach!
Die offensichtlichste Einschränkung ist: MySQLi kann nur MySQL. Das reicht mir nicht. Eine Umstellung zieht meist schon die Anpassung der SQL-Statements nach sich, da will ich nicht auch noch den Wrapper anpassen müssen.
Wieviele Umstellungen von wievielen Projekten musstest du bereits durchführen?
dedlfix.
-
Hello,
Die offensichtlichste Einschränkung ist: MySQLi kann nur MySQL. Das reicht mir nicht. Eine Umstellung zieht meist schon die Anpassung der SQL-Statements nach sich, da will ich nicht auch noch den Wrapper anpassen müssen.
Wieviele Umstellungen von wievielen Projekten musstest du bereits durchführen?
Es soll da sogar Projekte geben, die mit mehreren verschiedenen Datenbankmaschinen gleichzeitig arbeiten (müssen). ;-P
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Tach!
Es soll da sogar Projekte geben, die mit mehreren verschiedenen Datenbankmaschinen gleichzeitig arbeiten (müssen). ;-P
Wie relevant ist das für die anderen Projekte?
dedlfix.
-
welche anderen Projekte?
-
Tach!
welche anderen Projekte?
Projekte, die nicht "mehreren verschiedenen Datenbankmaschinen gleichzeitig arbeiten (müssen)".
dedlfix.
-
Hello,
welche anderen Projekte?
Projekte, die nicht "mehreren verschiedenen Datenbankmaschinen gleichzeitig arbeiten (müssen)".
das ist aber heutzutage bei jedem kommerziellen Projekt zu erwarten/befürchten. Hier möchte ich Gunnars ewig zitierte fortschreitende Erweiterungen mal auf die Betriebssystem- und Datenbankwelt übertragen.
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.
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.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
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.
-
Hello,
Bitte begründe die sehr starke Wortwahl "extrem kompliziert".
Das würde aber weit über eine kostenlose Veröffentlichung hinaus gehen :-O
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Ich sehe nicht, wo die Diskussion jetzt hinführen soll, es geht hier doch nicht um irgendwelche fiktiven Projekte, mit anderen fiktiven Anforderungen, oder um irgendwelche Datenbanken die von PDO nicht abgebildet werden. Topic ist: PDO vs. MySQLi. Wo ist denn jetzt die Begründung dafür, mir selbst Steine in den Weg zu legen? Ist doch viel sympatischer, einfach von Anfang an vorbereitet zu sein. PDO kann das, MySQLi nicht.
-
Tach!
Ich sehe nicht, wo die Diskussion jetzt hinführen soll, es geht hier doch nicht um irgendwelche fiktiven Projekte, mit anderen fiktiven Anforderungen, oder um irgendwelche Datenbanken die von PDO nicht abgebildet werden.
Ja, es geht am Ende immer um konkrete Projekte. Deswegen sehe ich nicht, dass es ein Hauptgrund sein muss, flexibel zu sein, wenn diese Felxilbilität letztlich gar nicht nötig ist oder nicht wie ursprünglich gedacht große Vorteile bringt.
Topic ist: PDO vs. MySQLi. Wo ist denn jetzt die Begründung dafür, mir selbst Steine in den Weg zu legen? Ist doch viel sympatischer, einfach von Anfang an vorbereitet zu sein. PDO kann das, MySQLi nicht.
Wenn die Steine in einem Weg liegen, den ich nie gehe, dann interessieren die mich nicht. Es geht auch nicht darum, Steine in den Weg zu legen, sondern ob die Steine überhaupt Steine sind oder nur ebenfalls grau aussehende Irrelefanten.
Für mich ist PDO nicht zu bevorzugen, weil man damit eine (selten notwendige) Flexibilität bekommt, sondern weil ich damit produktiver, weil einfacher arbeiten kann.
dedlfix.
-
Ja gut, dann spielen wir halt unterschiedlich Lotto, mit Spekulationen über mögliche Anforderungen einer fiktiven Zukunft. Der TO hat kein Projekt, ich habe meinen Vorteil mit meiner Lösung, du hast keinen Nachteil mit deiner Lösung.
-
-
-
-
Hallo TS,
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.
Ich beziehe mich nur auf den fetten Teil.
Nein. Definitiv nein. Welcher Betreiber eines EDV-Systems, der seinen Verstand nicht morgens unter der Dusche vergessen hat, gewährt Geschäftspartnern direkten Zugang zur eigenen Datenbank? Das ist unverantwortlich, unflexibel, unsicher, kurz: Unsinn. Ich kenne Großunternehmen, die seit den 60ern EDV betreiben, und die Software auf dem Zentralrechner besteht aus Monstern der Kreuz- und Querzugriffe. Zumeist nur auf Komponentenebene, nicht auf DB-Ebene. Trotzdem ist die Folge, dass viele Änderungen unglaublich aufwändig sind, weil sie auf unglaublich viele Systeme durchschlagen. Der Zentralklotz ist ein Knäuel, das in den 70ern entstand und seitdem immer nur weiter verknäuelter wurde.
Den Fehler, direkte Datenbankzugriffe auf Systeme anderer Unternehmen zu machen, habe ich dabei immerhin nirgends gesehen.
Wenn ich mit einem Geschäftspartner Daten austauschen will, schaffe ich eine Service-Schnittstelle, die vom Datenmodell und der Datenbank abstrahiert. Ob das technisch dann als SOAP-, REST- oder sonstwie definiertem Service implementiert wird, ist egal, aber jedenfalls lasse ich niemanden, der nicht meiner Kontrolle unterliegt, direkt auf meiner DB herumwuseln.
Andersrum sollte man sich als Konsument einer Datenlieferung auch nicht drauf einlassen, sich die Daten direkt aus der DB des Lieferanten zu holen. Sonst hängt man bei jeder Schema-Änderung am Fliegenfänger und muss anpassen. Nixda, ein vereinbartes Interface hat unveränderlich zu sein, und wenn der Lieferant seine Datenhaltung anpasst, liegt die Verantwortung für die Einhaltung der Interface-Vereinbarung bei ihm. Geht die Anpassung so weit, dass das nicht mehr geht, ist zunächst ein neues Interface abzustimmen und eine Übergangszeit mit Parallelbetrieb erforderlich. Anders kann man lose gekoppelte Systeme nicht betreiben.
Rolf
--
sumpsi - posui - clusi-
Hello,
Nein. Definitiv nein. Welcher Betreiber eines EDV-Systems, der seinen Verstand nicht morgens unter der Dusche vergessen hat, gewährt Geschäftspartnern direkten Zugang zur eigenen Datenbank?
Verwechselst Du da "Zugang dzu den Tabellen" mit "Zugang zu einer Datenbank-Schnittstelle"? Es gibt bei vielen Datenbanken spezielle Überwachungsmöglichkeiten für externe Zugriffe.
Das ist unverantwortlich, unflexibel, unsicher, kurz: Unsinn.
Das ist Unsinn abzutun ist sicherlich nur eine Entgleisung von Dir?
Warum sollte ich ein zusätzliches Produkt mit eigenen Sicherheitslücken an die Datenbank andocken, wenn das Datenbanksystem bereits alle Möglichkeiten liefert? Meistens reißt man sich mehr Löcher rein in das System, als man durch ein zusätzliches Andockmodul verhindern könnte.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo Tom,
ich habe Zugang zu den Tabellen gemeint, weil ich das so verstanden hatte, und ich bleibe dabei, dass "Unsinn" dafür der geeignete Begriff ist. Ich publiziere mein Datenbankschema nicht. Damit binde ich mir einen Klotz an's Bein, der zukünftige Schemaänderungen extrem erschwert.
Zugang zu Stored Procedures ist eine andere Sache. Da habe ich die Chance, Schemaänderungen zu kapseln. Dennoch sollte man das nicht tun, weil man dann einen DB-Server des Unternehmens von außen erreichbar machen muss. Sprich: den DB-Server in der DMZ aufstellen oder einen Tunnel durch die DMZ bohren. Ersteres wäre ein DB-Server, der replizierte Daten bereitstellen kann, oder der über eine Serverkopplung Views auf einen DB-Server im Backend bereitstellt. Tunnel durch die DMZ sollte man aus Security-Gründen definitiv vermeiden.
Als Unternehmen stelle ich, wenn möglich, nicht meine Daten extern bereit. Höchstens bestimmte Sichten auf Daten. Lieber aber Services, die nicht im DB-Server programmiert sind, sondern auf einem Service-Host laufen, der in der DMZ steht. Von dort aus werden Zugriffe ins Backend im Unternehmensnetz gemacht. Ein Backend-Service KANN die Datenbank sein. Aber vielleicht auch weitere Microservices im Backend.
Rolf
--
sumpsi - posui - clusi-
Hello,
ich habe Zugang zu den Tabellen gemeint, weil ich das so verstanden hatte, und ich bleibe dabei, dass "Unsinn" dafür der geeignete Begriff ist. Ich publiziere mein Datenbankschema nicht. Damit binde ich mir einen Klotz an's Bein, der zukünftige Schemaänderungen extrem erschwert.
Dann bin ich ja beruhigt!
Dass man möglichst alle diejenigen Geschäftsregeln in der Datenbank kapselt, die dort auch sinnvoll verwaltet werden können, ist schon seit Jahren meine Kernaussage. Wenn Du hier schon länger mitliest (tust Du doch?), dann solltest Du wissen, dass ich ein Freund von stored Routines (Procedures, Functions, Triggers) bei MySQL bin (bei anderen DBMS sowieso. Ich habe früher Informix und bTrieve-scalable bespielt.
Und dass man seine Tabellen nicht nach außen kehrt, sondern dafür Zugriffsfunktionen (Stored Procedures) erstellt, das weiß Jeder, der über Historie schreiben muss, auch über Selects und diejenigen, die sich jemals mit vertikalen Rechten beschäftigt haben.
Zugang zu Stored Procedures ist eine andere Sache.
Ausschließlicher Zugang zur DB über Stored Routines sollte immer das Ziel sein! Sowas baut man selbstverständlich nicht für eine Webapplikation mit 30 Zugriffen am Tag und einem Nutzer (Webserver) :-O
Da habe ich die Chance, Schemaänderungen zu kapseln. Dennoch sollte man das nicht tun, weil man dann einen DB-Server des Unternehmens von außen erreichbar machen muss. Sprich: den DB-Server in der DMZ aufstellen oder einen Tunnel durch die DMZ bohren. Ersteres wäre ein DB-Server, der replizierte Daten bereitstellen kann, oder der über eine Serverkopplung Views auf einen DB-Server im Backend bereitstellt. Tunnel durch die DMZ sollte man aus Security-Gründen definitiv vermeiden.
Oder man stellt gleich einen DB-Server für die Außenkontakte in die DMZ. Der enthält dann selbstverständlich nur replizierte Daten. Er muss aber genau definierte und überwachte Statements mit dem "innereren DB-Server" austauschen können.
Irgendwo muss immer kommuniziert werden! Wenn Du keinen Kontakt nach außen wünschst, dann kannst Du deinen Laden gleich schließen.
Ich wehre mich hier immer gegen die Pauschalschelte.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
-
-
-
-
-
-
-
-
Hi,
Wieviele [DBMS-]Umstellungen von wievielen Projekten musstest du bereits durchführen?
nunja, ich teste Repository-Klassen gerne auch, und nutze dafür i.d.R. eine sqlite in-memory DB statt einer MySQL-DB. Aber ansonsten ist es wahrlich eher selten.
Viele Grüße Matti
-
2? 3? Dieses Jahr grad eins, nächstes Jahr noch eins. Davon auszugehen, dass sich das DBMS nie, NIE, N I E ändert halte ich für naiv. Ich gehe ja auch nicht davon aus, für immer der einzige Entwickler zu sein, oder dass ein System immer in der gleichen Umgebung läuft. Genau aus der Einstellung heraus entstehen doch die Probleme. PDO ist das Paradebeispiel für modulare Programmierung bei relationalen Datenbanken. Da kann ich mir SQLite mocken und dann auf Postgres Cluster umstellen, DNS ändern, fertig. Zumindest was den Wrapper angeht, so lange man kein ORM haben will. Wozu soll ich mir den Klotz ans Bein binden? Nu weil ich es kann? Es gibt sicher Gründe für MySQLi, aber die hat hier bisher niemand genannt.
-
-