Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 16
Like Tree2Likes

Thema: mysql meets mysqli

  1. #1
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    mysql meets mysqli

    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? 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.

  2. #2
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    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" ... !

  3. #3
    rico2009 Guest

    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.

  4. #4
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    AW: mysql meets mysqli

    @Mod: Hierher verschoben? Hmm ... na, euer Laden, eure Regeln!

    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!

  5. #5
    j-l-n Guest

    AW: mysql meets mysqli

    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...

  6. #6
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    AW: mysql meets mysqli

    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.



    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.
    Geändert von SteelWheel (21-07-2014 um 15:06 Uhr)

  7. #7
    Avatar von mikdoe
    mikdoe ist offline Administrator
    registriert
    01-05-2010
    Beiträge
    7.718

    AW: mysql meets mysqli

    Zitat Zitat von SteelWheel Beitrag anzeigen
    @Mod: Hierher verschoben? Hmm ... na, euer Laden, eure Regeln!
    Das ist eine Ehre! In dieses Forum kommt nur brandaktuelles, kniffeliges oder sonst wie besonderes.
    j-l-n likes this.
    Das deutsche Javascript Forum http://forum.jswelt.de http://forum.jswelt.de/images/logoJsWeltForumV4_32x22.png
    Sorry wenn ich manchmal ohne Hallo und nur klein schreibe! Dann bin ich nicht unfreundlich sondern mit nervigem kleinem Touch Tablet zugange

  8. #8
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.695

    AW: mysql meets mysqli

    @SteelWheel: dein Problem mit der InnoDB sollte hier irgendwo verankert sein: MySQL :: MySQL 5.0 Reference Manual :: 14.2.13 Limits on InnoDB Tables

    Außerdem hat mysqli auch prepared statements und diese sollten dort auch verwendet werden... genauso wie bei PDO.

  9. #9
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    AW: mysql meets mysqli

    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 ...

  10. #10
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.695

    AW: mysql meets mysqli

    Zitat Zitat von SteelWheel Beitrag anzeigen
    "es ist da, und jetzt unbedingt nutzen"
    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).

  11. #11
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    AW: mysql meets mysqli

    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".

    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!

  12. #12
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.695

    AW: mysql meets mysqli

    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.
    Zitat Zitat von SteelWheel Beitrag anzeigen
    und gar nicht unübersichtlich
    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']));
    Zitat Zitat von SteelWheel Beitrag anzeigen
    Du darfst mir gern ein paar "baz" geben und ich sage Dir gern, was davon "übrig bleibt".
    Zeig' mir doch die Funktion und ich sag' dir, ob ich was finde, das durchgeht. Sicherheit durch Verschleierung ist keine Sicherheit.

  13. #13
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    AW: mysql meets mysqli

    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).

  14. #14
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.695

    AW: mysql meets mysqli

    Zitat Zitat von SteelWheel Beitrag anzeigen
    Ich finde es immer wieder sehr ungnädig, wie Du Informationen übergehst oder ignorierst - um dann eine unangebrachte Breitseite zu platzieren.
    Oh - wollte eigentlich keine Breitseite platzieren... und hab' auch nichts absichtlich übergangen/ignoriert.

    Zitat Zitat von SteelWheel Beitrag anzeigen
    Du sprichst nur von Escapen
    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.

    Zitat Zitat von SteelWheel Beitrag anzeigen
    ich von allen anderen Dingen, die ich nicht in einer DB benötige
    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.

    Zitat Zitat von SteelWheel Beitrag anzeigen
    bewusst nicht benutze
    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?

  15. #15
    SteelWheel ist offline Haudegen
    registriert
    18-07-2012
    Beiträge
    600

    AW: mysql meets mysqli

    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.

    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 ... 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.

    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).

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. alte mySQL auf mySQLi umstellen - Prblem mit einer Function
    Von dertypdernixkan im Forum Serverseitige Programmierung
    Antworten: 11
    Letzter Beitrag: 16-05-2014, 18:09
  2. Homer meets CSS
    Von dkdenz im Forum Best of WWW
    Antworten: 1
    Letzter Beitrag: 01-08-2008, 22:39
  3. [MYSQLi] Prepared Statements, unbekannte Parameteranzahl
    Von ZeitGeist im Forum Serverseitige Programmierung
    Antworten: 3
    Letzter Beitrag: 02-06-2008, 00:27
  4. BIRDY meets flash
    Von Comet im Forum Best of WWW
    Antworten: 4
    Letzter Beitrag: 07-01-2003, 22:49
  5. PHP meets JavaScript, wie geht das?
    Von Robert im Forum Serverseitige Programmierung
    Antworten: 5
    Letzter Beitrag: 28-04-2001, 15:29

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •