Zugriff auf mehrere Datenbanken unter Zend

Wenn man innerhalb einer Zend Anwendung auf verschiedenen Datenbanken (mysql, mssql, etc.) zugreifen möchte, kann die Verbindungen in der application.ini hinterlegen:

resources.db.adapter = "pdo_mysql"
resources.db.params.host = "localhost"
resources.db.params.username = "xxx"
resources.db.params.password = "yyy"
resources.db.params.dbname = "zzz"
resources.db.isDefaultTableAdapter = true
 
resources.multidb.db1.adapter = "Sqlsrv"
resources.multidb.db1.host = "server-1"
resources.multidb.db1.dbname = "xxx"
resources.multidb.db1.username = "yyy"
resources.multidb.db1.password = "zzz"
resources.multidb.db1.charset = utf8
...

Anschließend kann die Instanz des Adapters geholt werden:

$front=Zend_Controller_Front::getInstance();
$bootstrap=$front->getParam('bootstrap');
$resource=$bootstrap->getPluginResource('multidb');
/**
 * @var Zend_Db_Adapter_Sqlsrv
 */
$db=$resource->getDb('db1');

Super, oder?

Interoperabilität zwischen Typo3 und MSSQL

Wer sich schon einmal den Wiki-Eintrag zu MSSQL durchgelesen hat, wird schnell merken, dass Typo3 an der einen oder anderen Stelle nicht wirklich rund mit der Microsoft Datenbank zusammenarbeiten wird. Ob diese Info aus dem Wiki noch aktuell ist, steht auf einem anderen Blatt… dort aufgeführte Bugmeldungen wurden jedoch bereits behoben. Ich habe jedoch einige Blog-Einträge (siehe Links unten),  gefunden, die von “großem” Aufwand sprechen, ein Typo3 unter MSSQL zu installieren. Die Unterstützung scheint jedoch besser zu werden. Zumindest stellt eine PHP Installation unter Windows kein Problem mehr da. Wer den Typo-Source gern wie unter Linux mittels symbolischen Link in sein Projekt einbinden will, kann das auch unter Windows mit einem kleinen Tool Junction von Microsoft ermöglichen.

Für die Bildgenerierung muß ImageMagick und Ghostscript installiert werden. Auch dies ist für Windows verfügbar.

Das “Rewrite” von URLs erfordert Zusatzaufwand ist jedoch auch in einem Typo3-Wiki-Eintrag beschrieben.

Das größtes Problem, das ich sehe, sind jedoch die Erweiterungen, die nicht unbedingt mit MSSQL kompatibel sein müssen. Diese sind dann entsprechend zu testen.

Wer seine Webseite unter Typo3 betreiben will und Daten von einem Microsoft SQL Server benötigt, könnte auch das Typo3 auf MySQL betreiben. MySQL läuft problemlos auf einem Windows-Server und ist (mitterweile) auch dort nicht wesentlich langsamer als unter Linux. Die Daten des MSSQL-Servers können in einer eigenen (Extbase-)Extension verarbeitet und dargestellt werden. Ich denke da z. B. an ein Produktmodul, dass die Produkteinformationen aus dem ERP-System erhält. Leider habe ich die Vermutung, dass Extbase keine komfortables Möglichkeit für den Zugriff auf MSSQL bietet, zumindest habe ich dazu nichts gefunden. Mag sein, dass das mit Typo5 mit Flow besser wird, da dort wohl Doctrine als Abstraktionsschicht verwendet wird, aber bis dahin wird noch etwas Zeit vergehen.

Aber was spricht dagegen den Zugriff auf die Datenbank mit etwas anderem durchzuführen? Nix (naja, ein paar Argumente gibts sicherlich). Und wie? Beispielsweise mit dem Zend Framework. Ich habe dazu eine Extension geschrieben, die den Autoloader des ZF einbindet (Extension an erster Stelle laden “top”). In jeder anderen Extension kann mittels passendem Zend Adapter eine Verbindung aufgebaut werden. Natürlich gibt es auch damit das eine oder andere Problem z. B. funktioniert der für den Microsoft SQL Server benötigte Adapter nur mit der PHP Erweiterung sqlsrv und wird erst aber Microsoft SQL Server 2005 oder höher unterstützt (darunter funktionierte bei mir die limit(Anzahl, Offset) Funktion nicht korrekt… ich hab den Adapter abgeleitet und diese Funktion überschrieben). Ansonst kann man nicht das ORM von Extbase verwenden, aber zumindest kann man sich daran “orientieren”, indem man die Zugriffe auf MSSQL-Daten in einer Repository-Klasse kapselt.

Fazit:

Wenn man ein Typo3-System auf MSSQL betreiben will, kann dies sicherlich mit etwas Aufwand hinbekommen. Wenn man jedoch die Möglichkeit hat MySQL unter Windows zu betreiben, würde ich das auch tun. Meist liegen die Daten im Business-Umfeld auf Windows-Servern und stammen dann wohl von anderen Anwendungen, die sowieso durch eine spezielle Implementierung aufbereitet werden müssen.

Links:

Zend Framework und Liquibase

Wer ein größeres Projekt inklusive verschiedenen Lebenszyklen realisieren will, der muß sich auch um das Datenbankmanagement kümmern. Das Database Change Management Tool Liquibase bietet sich dafür an und ergänzt die fehlende Funktion des Zend-Frameworks. Ich möchte hier beschreiben, wie dies in ein Projekt integriert werden kann. Ich möchte hierbei auf den bereits veröffentlichen Artikel “Das Zend Framework – Ein Startversuch” aufbauen. Desweiteren habe ich eine grobe Beschreibung der Funktionalität von Liquibase in meinem Artikel “Datenbankmigration mit Liquibase” vorgenommen. Continue reading

Datenbankmigration mit Liquibase

Wer kennt folgendes Problem nicht: Man entwickelt ein System, das eine Datenbank nutzt und entwickelt zwar wunderbar unter Versionskontrolle, jedoch läuft die Datenbankentwicklung “nebenher”. Das Datenbankschema wird direkt z. B. unter phpmyadmin entwickelt. Das funktioniert bei einem Entwickler möglicherweise noch ganz wunderbar, sobald aber mehrere daran arbeiten, verliert man schnell den Überblick. Für die Implementierung einer eigenen Lösung fehlt natürlich die Zeit und das verwendete Framework (z. B. Zend) hat natürlich von Haus aus auch keine Lösung parat. Mit dem Datenbankmigrationstool Liquibase kann man solchen Problemen aus dem Weg gehen. Continue reading

Contao und InnoDB

Irgendwo im Internet habe ich gelesen, dass das Installationstool nicht mit InnoDB funktioniere. Jedoch hat das Anlegen einer neuen Tabelle mit der Contao Version 2.9.4 ohne Probleme funktioniert. Was nicht ging, ist der Wechsel der Engine einer bestehenden Tabelle von MyISAM zu InnoDB. Dies ist aber auch besser so und sollte immer manuell durchgeführt werden.

Fakten über MyISAM

- Ist die MySQL Standard-Speicher-Engine
- Jede MyISAM-Tabelle wird in drei Dateien auf der Festplatte gespeichert (.frm, .MYD, .MYI).
- Alle Daten werden mit dem niederwertigen Byte zuerst gespeichert. Somit können die Datendateien zwischen verschiedenen Plattformen kopiert werden. Für Embedded-Systeme gilt das nicht immer.
- Numerischen Schlüsselwerte werden mit dem höchstwertigen Byte zuerst gespeichert (bessere Indexkompression).
- Große Dateien werden unterstützt, sofern es keine Betriebssystembedingte Einschränkung gibt, sind das bis zu 256TB
- Keine Transaktionen
- Standardmäßig kann eine MyISAM-Tabelle maximal 64 Indizes haben. Jeder Indize kann bis zu 16 Spalten besitzen.
- Die Höchstlänge für Schlüssel beträgt standardmäßig 1000 Bytes
- Standardmäßig maximal 2^32 (~4.295E+09) Zeilen pro Tabelle.
- Eine AUTO_INCREMENT Spalte pro Tabelle
- Indizierung von BLOB und TEXT-Spalten (Full-text search index)
- Jede Zeichenspalte kann einen anderen Zeichensatz haben
- Die Summe der Längen der VARCHAR- und CHAR-Spalten in einer Tabelle kann bis zu 64KB betragen.
- Kein Clustering
- Locking ist auf Tabellenebene möglich
- Daten- und Indexdateien können in unterschiedliche Verzeichnisse/Festplatten gelegt werden, um mehr Geschwindigkeit zu erzielen.

Quelle: MySQL 5.1 Reference Manual :: 13 Storage Engines :: 13.5 The MyISAM Storage Engine

Eine Konvertierung zu InnoDB ist unter bestimmten Voraussetzungen möglich.