[MYSQL] mysql meets mysqli

S

SteelWheel

New member
Hallo zusammen,

es ist eine Mischung aus Verblüffung und Diskussion - eher letzteres, da ich eine Lösung (Plan B) bereits habe. Folgende Auffälligkeit hatte ich heute ...

- erstelle DB-Connect (mysqli; OOP, eigene Klasse)
- create temp table innerhalb des Connects
- wechsel in andere DB zwecks SELECT (gesteuert über die Klasse; quasi Soll/Ist-Vergleich)
- Rückkehr zur temp table, welche mit INSERTS beglückt werden sollte

Was in mysql_* noch für gewohnte Lässigkeit sorgte, sorgt bei mysqli_* für "table doesn't exist" und ein Eintrag in meinem Error-Log. Hmm ... der Grund war aufgrund "doesn't exist" schnell gefunden und kann eigentlich nur mit dem Wechsel der Datenbank zusammen hängen. ABER ...

Bei SO hatte ich dann ein Posting gefunden, der das sogar auf seinem einen Connect hatte - das Comment eines anderen Users beschrieb dies mit "manchmal muss man einfach gewöhnliche Tables für eine Lösung wählen" und bekam regen Zuspruch. Selbstredend, dass ich nun erstmal für alle "TEMPORARIES" einen Workaround embedded hab ... auffällig wurde es erst heute (Release war heute morgen; und benutzende User triggern direkt Probleme) - ich habe mich nun endlich in meinem Großprojekt (~ 800 MB) von mysql_* getrennt. Demnach ist mir das Verhalten etwas suspekt - und ich bin gewarnt wie alarmiert.

Gibt es da demnach "rein zufällig" noch mehr Dinge, die ich so ohne Weiteres nicht mehr machen sollte, aber von denen ich wissen müsste? :D Denn eigentlich empfand ich "temp tables" nicht als speziell ...

Selbstverständlich habe ich das natüüürlich manuell mal ausprobiert - habe hier in der Entwicklungsumgebung von Hand den CREATE gedroppt, Datenbank gewechselt, Spirenzchen gemacht, Rückkehr ... der gleiche CREATE sorgt dann für "already exists". Das muss also sehr speziell sein und in Verbindung mit php5.4 - daher meine Frage.

Es läuft jetzt bislang alles ruhig und sehr zufriedenstellend wie schnell (hossa!). Daher mal eine Frage in die Runde, ob irgendwer noch so eine "spezielle Beobachtung" für mich als Warnung hat ... vielen Dank.
 
AW: mysql meets mysqli: temporary table

Ja, es gibt noch durchaus ein paar Fälle, die unerwartet ein anderes Verhalten auslösen; bspw. ...
a) "MySQL Server has gone away" (offenbar in Verbindung mit sehr langen Queries [Inserts/Updates])
b) unerwarteten wie vorzeitigen Timeouts auf einer Connection [intervallgesteuerte, selbst ausführende Automationen sind dadurch nun "instabil"]

Ich habe daher (vorerst) zurück auf den "alten" PHP-Interpreter (5.2) für die betroffenen Automationen gestellt und schon lief das Spektakel wieder anstandslos (!). Hmm ...

However ... ich werde mit der Zeit mit Sicherheit (!) noch den einen oder anderen Stolperstein lokalisieren.

Hier kann also "zu" ... !
 
AW: mysql meets mysqli: temporary table

Ich finde das Thema sehr interessant. Ich bin auch gerade dabei, ein großes Projekt von mir neu aufzubauen und in diesem Zuge alle "alten" mysql_ Funktionen durch mysqli_ Funktionen zu ersetzen. Daher vielen Dank für die Info. Wenn du noch mehr entdeckst, kannst du ja mal Bescheid sagen.
 
@Mod: Hierher verschoben? Hmm ... na, euer Laden, eure Regeln! :D

Hallo zusammen,

bei meiner Arbeit an einem neuen Prototyp, der mir diese Kommunikationsprobleme abfängt (simpel, aber effektiv!), bin ich über ein paar Dinge gestolpert, die ich in dem Zusammenhang hier direkt erwähne - auch wenn es etwas weit entfernt ist.

InnoDB: "ist Pflicht und als DB-Engine zu verwenden" ... VETO! Es gibt Dinge, die lassen sich mit InnoDB nicht realisieren - bspw. das Speichern von umfangreicheren Internetseiten (nur Quellcode!). InnoDB kann es nicht, meldet hierzu aber auch nichts - die Spalte wird (mit etwas Glück) dann einfach gekürzt (bricht also irgendwo ab) oder bleibt ganz leer (Fehlermeldung gibt es hierzu keine!) ... hatte das bei einem eigenen Projekt im letzten Jahr und war verblüfft, dass er Quellcode partou nicht Speichern wollte. Ich bin über InnoDB jedenfalls gestolpert, da ich mit dem Engine-Type getestet hatte (gibt ja nicht nur MyISAM oder InnoDB, sondern - wg. dem "create temp table" - auch MEMORY oder ARCHIVE). Hier habe ich aber noch nicht weiter getestet ...

mysql, mysqli oder PDO: Ich bin immer ein wenig schockiert, wenn es heißt, dass PDO doch gefälligst zu nehmen wäre, wenn es um die Kommunikation mit einer Datenbank gehen würde. Wer jetzt zustimmt und denkt "natürlich", der darf kurz aufmerksam weiterlesen: Dass mysql_* ausgedient hat, ist völlig klar - das ist abzulösen und sollte mit PHP >= 5.3 nicht mehr zum Einsatz kommen. Die Wahl zwischen mysqli_* und PDO hingegen ist jedem selbst überlassen - und wenn nicht mehrere verschiedene Datenbanken in einem Projekt beteiligt sind, die die Einfachheit von PDO als Verbindungsschicht voraussetzt, ist mysqli_* die - wie offiziell auf der PHP-Seite zu finden ist (!) - "preferred option". Dass mysqli_* schlechte Kritik bekommt, liegt an der Zweigleisigkeit zwischen "prozedural" und "oop" und an dem vermeintlich möglichen "Mischbetrieb". Ist also etwas dreckiger verwendbar, da wohl möglich (hab es nicht getestet; bin mit meinem OOP-Ansatz zufrieden ^^), aber das liegt immer noch am Coder selbst ... :)

Ich habe mir dann einen Testlauf mit new mysqli("p:localhost" ...) gegönnt - eine fünfstellige Schleife mit einem "SELECT 1" enthalten auf eine Datenbank. Das Ergebnis war verblüffend hoch ... und verdammt schnell. Leider ist "p:" (persistente Verbindung) für mich (mit meinen ganzen Datenbanken) keine Option und man munkelt über "Restdaten bei Userwechsel bzw. Verbindungsübergabe". Aber der Test war schön ... ^^

Euch einen starken Montag, mir einen frischen Kaffee!
 
Mit deinen Anmerkungen zu PDO gebe ich dir recht. Obwohl ich dem gegenüber erst skeptisch war, finde ich aber mittlerweile nach einiger Arbeit damit PDO echt klasse...
 
Für mich als "alten Knacker" (naja, so schlimm auch noch nicht) und c64-Lötkolben-Schwinger (ich sag nur Peilwagen der Post!) wäre die Umstellung doch recht "gewöhnungsbedürftig". Was jahrelang mit nur "query" ging, soll jetzt - gem. PDO-Profis - aufgeteilt werden. Jene Datenbankbefehle weiterhin query(), andere aber mit exec() (o. ä.; kürzlich gelesen - suche ich nochmal raus, da in die Favs geworfen). Ich werde bestimmt meinen Weg ins PDO finden (nächstes, aber NEUES Projekt bspw.) - aber für das aktuelle Projekt, welches vollständig prozedural mal anfing [da war PHP4 gerade frisch], ist es mit heute 800 MB schwierig, PDO "mal eben" nachzujustieren. Mein nächster Plan ist es, eine bessere Befehlsverarbeitung mit auto-detect der Queries (Typus) oder simplem Argument für den Rückgabewert zu stricken und einzubetten. Wenn das dann alles geht, dann lässt sich später auch PDO mit Sicherheit besser reinlöten ... aber der Schritt von mysql_* (OOP) auf PDO wäre sehr schmerzhaft wie monströs zeitraubend geworden ...

Für den Umzug aus mysql_* auf mysqli_* hatte ich mir eine Klasse geschrieben, die mir die Dateien bei manueller Verzeichnisnennung automatisch darin ändert. Seeeeehr zeitsparend (trotz Entwicklungszeit für den Prototypen) ... statt mehreren Wochen (!) nur "zwei Tage" (Entwicklungszeit der Klasse); die ist aber leider incomplete (hatte zwei mysql_* nicht ergänzt). Der Quellcode ist an der Stelle jetzt mal falsch eingerückt - aber weiterhin funktional. ;) Wer von euch also auch immer einen Umzug dieser Art plant: macht es nicht manuell! (nein, denn Suchen & Ersetzen war hier auch keine Option; $rs hieß nicht immer $rs usw.)

So, genug gequatscht ... Zeit für ein wenig interplanetare Koffeinvernichtung. :D



EDIT: Zitat aus dem Tut -> Die Methode query ist ausschließlich für SELECT-Anweisungen gedacht. Für INSERT, UPDATE, REPLACE oder DELETE sollte man die schon erwähnte exec-Methode nutzen.
 
Zuletzt bearbeitet:
Danke für den Link, aber die Experimente von einst mit "longtext" etc. führten zu keinem anderen Ergebnis (ging um die Seiten von Audi oder BMW) - die von Dir verlinkte Seite kenne ich, da ich einst auf der Suche nach einer Lösung war und Ansätze suchte. Führte aber - wie erwähnt - nicht zu einer Lösung, sondern zu einer Umstellung der Engine. Grob umrissen: Seite curlen und den erhaltenen Quellcode 1:1 speichern - da gab es "Nebenwirkungen" mit PHP5.3 und einer MySQL5 ...

Da dies mein Thread ist, erlaube mir kurz eine rudimentäre Einstellung meinerseits kund zu tun: "sollte dort auch verwendet werden" ist etwas, wo ich "nö" sage. Ich habe den Konjunktiv zwar zur Kenntnis genommen (fürs Protokoll), aber ich bin GAR KEIN Freund von "es ist da, und jetzt unbedingt nutzen" (da hab ich schon zuviel erlebt). Das ist (in meinem Fall) ein Bestandsprojekt - keine Neuentwicklung. Die Umstellung zu vieler verwendeter Queries auf "ps" wäre ein apokalyptischer Albtraum. Es ist also eine Mischung aus "never change a running system" (es ist ein Schutz implementiert; läuft seit 7 oder 8 Jahren sehr erfolgreich und bewahrt mich vor einigem) und meiner Scheu vor Umstellung von Queries im fünffachen Bereich, was eine erhöhte Fehlerproblematik definitiv wieder mit sich führen würde (liegt an der Grundstruktur und dem Fehl einer zentralen Abwicklung auflaufender Queries per Automation und Rückgabe von entsprechender Resultqueries je Bedarf etc.).

Danke also für den Vorschlag/Hinweis/whatever. Und ich geb Dir recht, dass man für Neuprojekte das durchaus berücksichtigen sollte. Aber in diesem einen und (meinem) speziellen Fall bleibt es bei meinem Nö, obwohl ich weiß, dass es das gibt. ;) Das wird vielleicht irgendwann Thema ... genauso wie PDO (aber auch nur, falls seitens PHP was geändert wird (deprecated) oder ein Umzug auf eine andere Datenbank (also weg von MySQL) erforderlich wird).

Jetzt gern zurück zum eigentlichen Thema ... aktuell gibt es noch keine weiteren Erkenntnisse meinerseits, "p:" wird - wie erwähnt - hier nicht eingesetzt werden (auch, wenn schnell) und der Prototyp ist noch nicht soweit und ein Test auf dem Live-System ist immer so eine Sache (würde aber den Usern angekündigt werden). Es ist auch das einzige Problem, was es jetzt noch wirklich gibt ... Timeout, "gone away" ... die Lösung ist da, aber noch nicht eingebettet und getestet und Echt-Bedingungen. Ich werde hier auf jeden Fall noch mitmeißeln lassen, welcher Query hier u. U. "zu lang" ist (falls es sich bewahrheitet). Dann kann ich euch zumindest mal eine mb_strlen()/strlen() geben. ;)

Falls ihr noch was habt oder hört, nur her damit ...
 
SteelWheel schrieb:
"es ist da, und jetzt unbedingt nutzen"
Zum Vergrößern anklicken....
So war das auch gar nicht gemeint. Prepared statements sind um einiges einfacher und leichter zu lesen als das dauernde maskieren/validieren und bieten mehr Schutz (man übersieht einfach zu leicht mal was).

Außerdem ist es schon ziemlich lang "da" (seit PHP 5.0.0).
 
Wie gesagt: Ich gebe Dir völlig recht, dass man das durchaus beherzigen sollte, wenn und eben nicht 'nen Sonderling (meint nicht mich! ^^) hat. Ich zeig Dir mal einen stark abgewandelten Eintrag bei mir - bzgl. "leichter zu lesen".

Code: 
$insert = "INSERT INTO 
	`foo`
SET 
	`bar`='" . funcXssCleanUp($_POST['baz_mit_evil_code'], $param) . "';";

Die Funktion selbst arbeitet mit regulären Ausdrücken und killt so ziemlich alles (toi toi toi), womit sich irgendwie Unfug anstellen lässt und ich gar nicht benötige. Der streicht also einfach nur radikal unerwünschte Dinge heraus (bspw. Verwendung von "&#", CSS-Hacks im IE (der konnte mal JavaScript via Inline-CSS) u. v. m.). Sind aber auch nur fünf oder sechs Regeln (schon lange her), aber eben "sehr gut" (für meinen Geschmack) ... eines noch: $param regelt, wie strikt er sein soll. Hier unterscheide ich - je nach Verwendung -, ob der Benutzer direkt als Aggressor gewertet wird (mb_strlen() nach trim() <> mb_strlen() nach func()).

Du darfst mir gern ein paar "baz" geben und ich sage Dir gern, was davon "übrig bleibt". :D

Aber das ist meine Lösung (und gar nicht unübersichtlich). :) Die ist nicht geeignet für andere - also nochmal, damit Du es kein drittes Mal überlesen kannst: Ich gebe Dir recht! :D
 
Das escapen bei den MySQL-Queries hat aber überhaupt nichts mit XSS zu tun, sondern mit SQL-Injections... das ist dir hoffentlich klar... XSS muss eigentlich an einer anderen Stelle abgefangen werden: wenn du den Inhalt der DB ins HTML schreibst.
und als Außenstehender muss ich erst mal nachsehen, ob funcXssCleanUp auch wirklich das macht, was es soll, und $param macht's nicht besser - da kann ja auch mal was falsches drin stehen. Wäre mir viel zu komplex und Komplexität ist gerne mal der Feind von Sicherheit.
SteelWheel schrieb:
und gar nicht unübersichtlich
Zum Vergrößern anklicken....
Doch - für einen Außenstehenden schon... also ich find' unübersichtlich. Viel zu viele Variablen, an denen gedreht werden kann.
Code: 
$stmt = $link->prepare("INSERT INTO 
	`foo`
SET 
	`bar`= ?;");
$stmt->bind_param("s", $_POST['baz_mit_evil_code']);
$stmt->execute();
macht immer das, was es soll. Wobei ich mysqli hier nicht besonders mag - das ist mir zu manuell (v.A. das "s" nervt). PDO ist da viel schöner:
Code: 
$stmt = $pdo->prepare("INSERT INTO 
	`foo`
SET 
	`bar`= :bar;");
$stmt->execute(array(":bar" => $_POST['baz_mit_evil_code']));

SteelWheel schrieb:
Du darfst mir gern ein paar "baz" geben und ich sage Dir gern, was davon "übrig bleibt".
Zum Vergrößern anklicken....
Zeig' mir doch die Funktion und ich sag' dir, ob ich was finde, das durchgeht. Sicherheit durch Verschleierung ist keine Sicherheit.
 
Vielleicht liegt es daran, dass ich bislang noch keinen Kaffee bekommen habe: Ich finde es immer wieder sehr ungnädig, wie Du Informationen übergehst oder ignorierst - um dann eine unangebrachte Breitseite zu platzieren. Aber vielleicht wirkt das auch nur auf mich so, da wir uns noch gar nicht all zu lange kennen/schreiben. Ich erspare uns beiden jetzt jedenfalls Wiederholungen, da der Hauch "Rechtfertigung", der dadurch entstünde, gar nicht passen würde (in diesem Fall). Du sprichst nur von Escapen - ich von allen anderen Dingen, die ich nicht in einer DB benötige (und das schließt XSS mind. mit ein; in Langform: "und das schließt Maßnahmen via Quellcode mit ein, die die Logik und Anwendbarkeit von XSS ermöglicht" - bevor eine weitere Belehrung meint entstehen zu müssen). Dennoch erneut ein Dankeschön für die (zumindest mir) bekannte Verwendung von "prepared statements", welche ich aber - jetzt wird ein Kreis draus - bewusst nicht benutze (das hat nichts mit der erwähnten func() zu tun).
 
SteelWheel schrieb:
Ich finde es immer wieder sehr ungnädig, wie Du Informationen übergehst oder ignorierst - um dann eine unangebrachte Breitseite zu platzieren.
Zum Vergrößern anklicken....
Oh - wollte eigentlich keine Breitseite platzieren... und hab' auch nichts absichtlich übergangen/ignoriert.

SteelWheel schrieb:
Du sprichst nur von Escapen
Zum Vergrößern anklicken....
Ja - für was anderes sind prepared statements auch nicht gedacht. Was anderes können sie auch nicht - das können sie dafür sehr gut.

SteelWheel schrieb:
ich von allen anderen Dingen, die ich nicht in einer DB benötige
Zum Vergrößern anklicken....
Genau das ist meine Meinung: die XSS-Verteidigungslinie sollte nichts mit der DB zu tun haben.

Das sollte man, meiner Meinung nach, möglichst entkoppeln um die Komplexität der Einzelkomponenten zu reduzieren, was wiederum die Fehleranfälligkeit vermident.

SteelWheel schrieb:
bewusst nicht benutze
Zum Vergrößern anklicken....
Warum nicht? Soll jetzt kein Angriff sein - bin einfach nur neugierig. Oder meist du bei Bestandsprojekten, bei denen es zu aufwändig wäre es umzustellen?
 
Grüße Dich, JETZT kam das bei Dir an, was ich mit "übergehen/ignorieren" meinte - und ich bin froh, dass das keine merkwürdige Baustelle damit ist/wird. :D

Die Umstellung (im Bestandsprojekt!) auf "ps" ist ein ultimativer Aufwand - und er steht in keinem Verhältnis zum späteren Nutzen (denn es läuft bekanntlich). Ich rede in diesem Projekt ausnahmslos und nur von einem Projekt (908 MB ... gestrige Messung; davon 345 MB Datenbank). Diese Umstellung auf "ps" ließe sich auch nicht automatisieren - und hätte durchaus denkbare wie fatale Auswirkungen auf den Betrieb. Ich hab schon drei Kreuze gemacht, dass ich jetzt das "i" bei "mysql" nun habe ... :D Es wird jetzt weiter gestrafft und möglich "global umstrukturiert" - da ist sehr viel OOP drin, aber da geht noch mehr. Aber die User meckern, wollen Neuerungen und Änderungen ... da ist Scriptpflege und -optimierung überhaupt keine Option. :D

Fazit: Es geht nur um ein Bestandsprojekt, was von mysql auf mysqli umgezogen ist - die Verwendung von "ps" bei neuen Projekten (wie geschrieben) ist zu benutzen (gerade für Einsteiger, die nicht immer wissen, was sie tun). :D
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben