Also so was sollte ja nicht vorkomen oder ?

• MySQL.com Vulnerable To Blind SQL Injection Vulnerability

[+] MySQL.com Vulnerable To Blind SQL Injection vulnerability
[+] Author: Jackh4xor @ w4ck1ng
[+] Site: http://www.jackh4xor.com

Gut MySQL kann nicht direkt was dafür, denn die Anwendung die mit der DB arbeitet hat da was verkackt, aber es ist trotzdem FAIL.

MySQL Workbench zu verstehen ist am Anfang ein wenig schwer, aber dieses Tutorial sollte da Abhilfe schaffen:

In today’s tutorial, you’ll learn how to use a visual database modeling utility to draw a database diagram and automatically generate SQL. Specifically, we’ll review how to use MySQL Workbench, a cross-platform, visual database design tool.

Visual Database Creation with MySQL Workbench

Zeit dem Kauf von MySQL durch Oracle hatte man ja angst wie es nun mit MySQL weitergehen soll.

Nun haben sich die Verantwortlichen auf der O'Reilly MySQL Conference & Expo zu Wort gemeldet

Gegenüber Reuters erklärte Edward Screven, Chief Corporate Architect bei Oracle, sein Unternehmen werde die Investitionen in MySQL erhöhen, damit sie besser mit Microsofts SQL-Server konkurrieren kann. Dabei solle MySQL allerdings weiterhin eine schlanke, leicht zu administrierende Datenbank bleiben, sagte Screvens auf der Konferenz.

Hier der Reuters Bericht und hier die Heise Open Nachricht mit mehr Infos.

Nun hat die Geschichte ein Ende und ich denke alle sind froh, dass MySQL nicht auf kosten von Oracle gestorben ist.

Via: pop-urls.de

Jeder kennt ja die Pagination bzw. die Blätterfunktion für die Anzeige einer Liste.

Man will ja nicht immer alle Daten auslesen, sondern nur die die auch auf der Seite angezeigt werden sollen.

Bisher führt man ja die Abfrage 2 mal aus. Einmal mit LIMIT und einemal ohne. Ansonsten kommt man ja nicht an die Anzahl der Einträge um herauszufinden wie viele Seiten es denn gibt.

Damit hat man aber eine Abfrage 2 mal ausgeführt und das kann bei vielen Datenbeständen zu Problemen führen. ( ich rede hier im 1000+ Bereich )

Nun gibt es aber ab MySQL 5.0 4.1 eine neue Variable die man schon im SELECT Statement mitgeben kann.

SQL_CALC_FOUND_ROWS

Dies kann man dann mit der folgenden Funktion abgfragen.

FOUND_ROWS()

Ich werde das nicht nochmals wiederholen, dann in der Manual ist das schön erklart:

A SELECT statement may include a LIMIT clause to restrict the number of rows the server returns to the client. In some cases, it is desirable to know how many rows the statement would have returned without the LIMIT, but without running the statement again. To obtain this row count, include a SQL_CALC_FOUND_ROWS option in the SELECT statement, and then invoke FOUND_ROWS() afterward: (...)

Damit spart man performance, denn man muss die selbe Abfrage nicht 2 mal machen und PHP muss nicht nochmals das Ergebnis der Abfrage bearbeiten.

Wer schon immer wissen wollte wie man MySQL Abfragen besser machen kann und somit auch Performance verbessert dem sei hiermit geholfen:

Optimization is a complex task because ultimately it requires understanding of the entire system to be optimized. Although it may be possible to perform some local optimizations with little knowledge of your system or application, the more optimal you want your system to become, the more you must know about it.

10 great articles for optimizing MySQL queries ( PHP::Impact ( [str Blog] ) )

Banana
out

Sollte man mal den Fall haben Daten in eine Tabelle zu speichern und voher zu unterscheiden ob diese Daten schon vorhanden sind und aktualisiert werden müssen oder neu sind.

Dies lässt sich zeit MySQL 4.1 in einem Befehl machen

INSERT INTO access ('news','text','date') 
VALUES ('news tasda', 'tex ad asd t', '01.01.1900')
ON DUPLICATE KEY UPDATE news = 'neuerInhalt', 
text = 'neuer Text', 
Datum = 'neues Datum' ;

In diesem Beispiel sollte die Spalte news der Primär Schlüssel sein.
Mit einer vortlaufenden ID als Primärschlüssel geht das nicht.
Es muss ein eindeutger Wert sein, denn ansonsten funktioniert ON DUPLICATE KEY nicht.

MYSQL HandbuchReferenz