About Daniel Kyak

Trockene technische Themen mit Leben zu füllen und die Ideen von Konzeption und Design Wirklichkeit werden zu lassen, ist mein täglich Brot als Senior Systems Engineer bei der New Identity AG. Als gebürtiger Hallenser habe ich nach Abschluss meines Wirtschaftsinformatikstudiums eine zweite Heimat in Mainz gefunden.

Das erste Mal für die PHPUG Rheinhessen

Ich bin gerade zurück vom ersten Treffen der PHP Usergroup Rheinhessen in den Räumen von netz98. Unabhängig von den Vorträgen und der Diskussion konnte ich Folgendes feststellen:

  1. Eine Wii gehört zur Standardausrüstung einer guten Firma. Da fällt mir ein: Wer ist eigentlich im Halbfinale beim NIDAG-Wii-Bowling-Turnier? Ich habe es ja nur bis zum Viertelfinale geschafft.
  2. Mit 21 Leuten waren überraschend viele da und ich habe sogar schon jemanden gekannt! Es sollen sogar welche, von der anderen Rheinseite da gewesen sein. Vielleicht könnte man ja doch den Namen in PHPUG Rhein/Main ändern, zumal die PHPUG Frankfurt faktisch tot ist.
  3. Mehr Entwicklerinnen braucht das Land! (Wir waren eine reine Männerrunde.)
  4. Es ist richtig praktisch, McDonalds direkt vor der Tür zu haben, wenn der Hunger kommt!

Wenn man das Treffen aus der PHP Sicht betrachtet, war es auch ganz gut. Ich mag ja diese Blicke über den Tellerrand bei denen man immer einen Einblick auf Dinge bekommt, mit denen sich Andere gerade beschäftigen. Genau dafür ist so ein Treffen perfekt! Kleine übersichtliche Vorträge mit guter Diskussion, die sich nicht nur an der Oberfläche bewegen. Ich hoffe, das Treffen bleibt keine einmalige Sache. Wäre schön, wenn es sich so entwickelt, wie der Webmontag in Frankfurt, zu dem ich nächsten Montag wieder aufbrechen werde. Nach der aktuellen Meldeliste kommen dort nächsten Montag fast 80 Leute zusammen. Manches Barcamp wäre froh, wenn es so viele Teilnehmer hätte!

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`);

Wie bekomme ich mein Adressbuch ins iPhone?

Vor kurzem habe ich mir ein Smartphone zugelegt. Eine gute Entscheidung, die ich bisher auch noch nicht bereue. Die Wahl fiel auf ein iPhone, was am Ende ein spontaner Entschluss nach längerem hin und her war.

Eine der ersten Fragen, die sich mir stellte war: Wie bekomme ich mein Adressbuch ins iPhone?

Mit Outlook ist der Adressbuchabgleich wohl kein Problem, da es ja eine entsprechende Option in iTunes gibt. Nur nutze ich Mozilla Thunderbird zur Verwaltung meines Adressbuches und einen Wechsel zu Outlook kam für mich nicht in Frage. Also ging ich auf die Suche nach einer Lösung mit Thunderbird. Die erste Suche ergab irgendwie keine überzeugenden Ergebnisse, daher ging es nun mit etwas herumprobieren weiter.

Continue reading