Installation der XAMPP Entwicklungsumgebung unter Windows

This entry is part 5 of 4 in the series Zend Framework Grundlagen

Herzlich Willkommen zum ersten Teil unseres Zend Framework Grundlagen Workshops. Die ersten Artikel werden sich an Einsteiger richten und mit den grundlegenden Basics anfangen. Heute werden wir eine XAMPP (X Apache, MySQL, PHP, Perl) Entwicklungsumgebung unter Windows installieren und für die Nutzung mit mehreren virtuellen Hosts konfigurieren.

Continue reading

MySQL und der Query Cache

Ich war und bin eigentlich ein Verfechter der Aussage: „Alles was mit Hilfe eines Datenbankstatements umgesetzt werden kann, sollte auch durch ein Datenbankstatement umgesetzt werden.”
Neben der Reduzierung der Logik innerhalb der Anwendung ist dieser Ansatz meist auch performanter, da gleiche Abfragen durch die Datenbank schneller abgearbeitet werden können.

Meist, denn wie ich nun gelernt habe, gibt es unter bestimmten Bedingungen in MySQL Ausnahmen.

Nehmen wir an, es wird in einem Projekt der MySQL Query Cache eingesetzt. Eine gute Idee, denn so können Abfragen wirklich sehr viel schneller ausgeführt werden. Wenn man den MySQL Query Cache einsetzen will, sollten einem aber auf jeden Fall auch die Rahmenbedingungen bewusst sein. Beschrieben sind diese in einem eigenen Kapitel in der MySQL Dokumentation. Für die Statements sind meiner Meinung nach besonders die folgenden zwei Punkte zu beachten:

  1. Hart aber auch naheliegend ist, dass die Verwendung einiger Date und Time-Funktionen nicht möglich ist. Dazu zählen CURDATE(), CURRENT_DATE(), CURRENT_TIME(), CURTIME(), NOW(), CURRENT_TIMESTAMP()SYSDATE() und UNIX_TIMESTAMP(). Mit diesen Date/Time-Funktionen wird der aktuelle Zeitpunkt ermittelt und dieser ändert sich natürlich regelmäßig, wodurch der Cache wieder direkt ungültig wäre. Umgehen kann man dies allerdings recht einfach indem man die Werte für beispielsweise das Datum durch die Anwendung mit übergibt. Somit wäre beispielsweise auch das folgende Statement cachebar:
    SELECT * FROM `page` WHERE `date` > "2009-12-12 00:00:00";
  2. Das Prepared Statements auch nicht gecacht werden konnten, hat mich dagegen schon mehr überrascht. Gerade da mit ihrer Hilfe häufig nacheinander ausgeführte Abfragen beschleunigt werden können. Aber hier hilft zum Glück ein Update auf eine neue MySQL-Version und dann geht es. Die Version 5.1.21 sollte es dabei allerdings schon sein, wenn man der entsprechenden Dokumentation glauben darf.

Ferner darf man natürlich auch nicht übersehen, dass Veränderung an den zugrundeliegenden Tabellen zur Invalidierung des Query Caches führen. Daher sollten diese Operationen bewusst eingesetzt werden, um den Query Cache nicht obsolet zu machen.

Reverse Engineering mit MySQL Workbench

Eigentlich sollte man ja immer zunächst mit einem Entity-Relationship-Modell (ERM) beginnen und dann erst in die Umsetzung gehen. Im Alltag ist dies allerdings meist anders, was verschiedene Gründe haben kann. Einerseits existieren schon Datenbankstrukturen aus vorhergehenden Projekten, welche angepasst und erweitert werden sollen. Andererseits werden durch Tools und Frameworks, wie Doctrine, Datenbankstrukturen automatisch erstellt.

Um dann von diesen Struktur ein ERM zu erhalten, könnte man es natürlich manuell nachmodellieren. Eine andere Möglichkeit bietet dabei zum Beispiel MySQL Workbench. Mittels MySQL Workbench ist es möglich ERMs recht schnell aus vorhandenen MySQL-Datenbanken zu erstellen. Wie einfach dieses Reverse Engineering von der Datenbank zum Modell geht, will ich hier mal kurz beschreiben.

Der erste Schritt ist die Installation der neusten Version von MySQL Workbench. Ich habe mich für die Version 5.2.10-beta entschieden. Nachdem dies geschehen ist und man ein neues Modell erstellt hat (“File -> New Model”), kann man mit der eigentlichen Erstellung des Datenmodells beginnen. Dazu gibt es unter “Database -> Reverse Engineer” die nötigen Eingabemasken für die Verbindung zum Datenbankserver und der Auswahl der Datenbank.  Hier müssen nur die 7 Schritte des Prozesses durchlaufen werden, was in meinem Beispiel zu keinen Problemen führte. Ist der Prozess durchlaufen erhält man alle Tabellen und ihre Verbindungen und man kann mit dem Platzieren der einzelnen Tabellen und Verbindungen beginnen. Hat man dann auch ein rein optisch ansprechendes Ergebnis erstellt, lässt sich dies in verschiedene Formate exportieren (“File -> Export”) und für die Projektdokumentation ablegen. Das ERM lässt sich natürlich auch immer gut als Wanddekoration im Büro nutzen. ;-)

Tipp: Es empfiehlt sich bei der Datenstruktur Constraints zwischen den Tabellen zu erstellen. Diese Contraints werden dann automatisch als Fremdschlüssel in das ERM aufgenommen und dargestellt.

ALTER TABLE `product_comment`
 ADD CONSTRAINT `product_comment_ibfk_1` FOREIGN KEY (`product_id`) REFERENCES `product` (`product_id`),
 ADD CONSTRAINT `product_comment_ibfk_2` FOREIGN KEY (`customer_id`) REFERENCES `user` (`customer_id`);