Man öffne die Datei config.inc.php und füge nach der Server-Konfiguration die folgenden Zeilen ein:

$cfg['DefaultTabTable'] = 'tbl_structure.php';
$cfg['LeftDefaultTabTable'] = 'tbl_structure.php';
$cfg['SQLQuery']['Edit'] = TRUE;

Zur Erklärung: Klickt man links in die Spaltenansicht aller Tabellen, so öffnete die alte Version standardmäßig die Tabellenstruktur, nun sind es die ersten 30 Einträge. Diese Umstellung wird durch die erste und zweite Zeile rückgängig gemacht. Sicherlich werden viele die Einträge auch gern sehen wollen. In meinem Falle benutze ich phpmyadmin nicht unbedingt zur Datenrecherche, sondern ganz oft für Arbeiten an der MySQL-Tabellenstruktur. Dafür finde ich die alte Einstiegsseite besser geeignet.

Die letzte Zeile korrigiert den fehlenden “Bearbeiten”-Link, nachdem ein Query an MySQL abgesetzt wurde. Denn häufig starte ich damit, einen ersten Query-Entwurf abzusetzen, dann mittels “Bearbeiten” ein Popup-Fenster zu öffnen, um dort mein Query weiter feiner zu granulieren, ohne dass ein Klick im Browserfenster mein Query verwirft.

Ansonsten kann ich das Update schon aus Sicherheitsgründen nur wärmstens empfehlen!

Das ist allerdings nicht ganz so easy, wenn sich die Daten des Satzes in verschiedenen Tabellen befinden. Also muss man die sich mühevoll zusammenklauben. Bei uns im Shop sind es eigentlich nur eine Handvoll Tabellen: Der Artikeleintrag in der Warenwirtschaft, die Varianten, die Preise, Rabatte, Shop-Eintrag, Shop-Texte und Shop-Fotos.

Die Einträge wurden aus eben diese Tabellen zusammengesucht. Aus Performance-Gründen bieten sich hier Stored Procedures an:
DELIMITER ‘$’;
CREATE FUNCTION f_getModified(…xyz…) RETURNS Datetime READS SQL DATA
BEGIN
DECLARE last DATETIME;
DECLARE cur DATETIME;
SELECT Timestamp INTO last FROM Tbl_XYZ INTO last WHERE xyz;
SELECT Timestamp INTO cur FROM Tbl_XYZ cur WHERE xyz;
SET last = IF(cur > last, cur, last);
…
RETURN last;
END$
DELIMITER ‘;’$

Natürlich schrumpft die Performance bei zunehmender Fragmentierung der Produktdaten erheblich, da die Berechnungskosten linear steigen. Aus diesem Grund habe ich überlegt, die Tabellen über INNER JOINS zu verknüpfen, und die Zeitstempel zunächst in einem Ritt zu holen:
DELIMITER ‘$’;
CREATE FUNCTION f_getModified(…xyz…) RETURNS Datetime READS SQL DATA
BEGIN
DECLARE last DATETIME;
DECLARE cur DATETIME;
SELECT a.Timestamp, b.Timestamp INTO last,cur FROM Tbl_XYZ a INNER JOIN TblXYZ b ON a.x=b.x AND a.y=b.y WHERE xyz;
SET last = IF(cur > last, cur, last);
RETURN last;
END$
DELIMITER ‘;’$

Auf meine 7 Tabellen angewendet, gibt das immerhin einen 10%-igen Performance-Schub. Nicht unerheblich, aber trotzdem nicht der Bringer. Anfangs waren es über 50% Geschwindigkeitsvorteil, als ich mit einfachen INNER JOINS über die ersten Tabellen arbeitete. Doch da es nicht immer entsprechende Einträge geben muss, ist man hier und da gezwungen, ein paar LEFT JOIN einzusetzen, welche als OUTER JOIN natürlich langsamer sind.

Ein weiteres Problem ist, dass nicht alle Tabellen einen Eintrag pro Produkt bieten, d.h. an dieser Stelle sind Sub-SELECTS vonnötigen, die den Zeitstempel über MAX(Timestamp) zunächst in der Ziel-Tabelle aggregieren, bevor der INNER JOIN einsetzt.

Letztendlich hatte ich bei einer entsprechend aufbereiteten Seite doch eher dazu tendiert, die bereits mit dem PHP-Script ausgelesenen Timestamps und die fehlenden Stempel per Hash-Scan zu ergänzen. An dieser Stelle konnte ich die Kosten für die Zeitstempel auf 20% der Procedure-Kosten drücken – allerdings ist diese Vorgehensweise nicht an allen Stellen die beste.

Doch bietet eine Seite nicht auch noch mehr? FAQs? Bewertungen? Mitkaufartikel? Hat sich die Seite nicht auch deswegen geändert, weil hier und da ein Eintrag dazugekommen ist? Was passiert, wenn sich eine Seite geändert hat, weil ein Eintrag wegfiel? Gar nicht so einfach, und ich möchte gern wissen, wie das “große” Shops so machen…Wer Ideen hat, ist zum Posten gerne eingeladen!

Außerdem verwenden wir für 90% unserer Daten MyISAM-Tabellen, die sich jedoch nur schwer mit Postgres vergleichen lassen. Da sollte man schon InnoDB verwenden und auf dieselben Features zurückgreifen, zum Beispiel Transaktionen, Referentielle Integrität oder Row Level Locking, welches ich mal mit zeilenbasiertes Sperren übersetzen möchte.

Es gibt jedoch eine Menge Sites, die aus ihren eigenen Tests die eine oder andere Datenbank stets als schneller evaluiert haben, zB Drupal. Man sollte da einfach mal nach “MySQL Postgres” googlen. Man kann dabei aber schnell ins religiöse Halblicht reingezogen werden. Die Tests werden meist von Advocacies und Flamewars begleitet, die dann meistens die Tests selbst als ungenügend kritisieren oder alles für alte Banane abtun, da Version X.Y.4a ihres Lieblingsprodukts ja alle genannten Kritikpunkte wegsprenge.

Richtig ist: Features und Konsistenz bedürfen nun mal Rechenzeit. Je nachdem, wie gut das DBMS programmiert ist, wählt es für jede der Aufgaben den minimalen Mechanismus im Sinne der zugrundeliegenden Architektur. Daraus ergeben sich für die ein oder andere Funktion verschiedene Laufzeiten. Im großen und ganzen sollte die Summe jedoch recht ausgeglichen sein.

Beide Datenbanken haben in den letzten Jahren durch den Hype von Open Source Software im Business-Umfeld offensichtlich stark zugelegt. Nicht zuletzt, weil die Anzahl der Installation und damit auch Anforderungen an diese und das Bug-Reporting ordentlich anstiegen. Dass die Daten gut verpackt und fehlerfrei so rauskommen, wie man diese einmal reingeworfen hat, das kann man beiden System also ohne Zweifel voraussetzen.

Wichtig im Sinne eines stressfreien Einsatzes erscheinen mir daher eher solche Dinge wie Installationshandling, Rechteverwaltung, Unterstützung häufiger Datenmanipulationsaufgaben oder In- bzw. Export von Daten.  Für Profis eventuell noch wichtig: Replikation, Failover oder Backup. Am meisten interessiert sicherlich das Gros der Leute, ob die PHP-Anbindung sauber funktioniert und alle Aufgaben einwandfrei unterstützt werden.

Wenn man mehrere parallele Threads laufen hat, zB bei gleichzeitigen Zugriffen auf eine gut besuchte Webseite mit vielen Datenbankoperationen, zählen sicherlich auch noch  andere Performance-Werte:

• Die Anzahl der konkurrierenden Zugriffe
• der dabei entstehende Speicherbedarf (“memory footprint”)
• das initiale Delay einer Abfrage.

Allerdings sind das Sphären, in denen die meisten DBA zu Replikation greifen werden. Wenn ein Server so am Anschlag ist, dann gibt man ihm doch am besten einen Partner zur Hand.

Deshalb habe ich beschlossen, es vorerst bei MySQL zu belassen. Ich werde also erst einmal schauen, was InnoDB mit Row Level Locking und Referenzieller Integrität für mich noch an Vorteilen zu bieten hat. Hier allein lassen sich schon Performance-Vergleiche anstellen und deren Ergebnisse im Alltag effektiv nutzen.

Erst dann kommt dann Postgres dran – zunächst wird es mir ums Handling gehen und später um die Performance – und zwar genau an den auch für InnoDB geeigneten Stellen. An dieser Stelle wird davon zu lesen sein.

Stay tuned !

INSERT INTO tabelle (Feld1, Feld2, Feld3) VALUES ((val1-1, val1-2, val1-3),(val2-1, val2-2, val2-3));

Soweit so gut. Doch bei 500,000 Einträgen in einer vielleicht nicht ganz so schmalen Tabelle stellt sich mir natürlich die Frage: Wie spielt man dann ein paar Sätze gezielt zurück, falls mal jemand aus Versehen etwas gelöscht hat?

Die Fiddelei möchte ich dann doch nicht am Bein haben. Nach etwas Ausprobierei fand ich heraus, dass man mit der Option –extended-insert=FALSE den “alten” mysqldump wieder zurückbekommt. Dann wird pro Tabelleneintrag ein INSERT-Befehl erstellt:

INSERT INTO tabelle (Feld1, Feld2, Feld3) VALUES (val1-1, val1-2, val1-3);
INSERT INTO tabelle (Feld1, Feld2, Feld3) VALUES (val2-1, val2-2, val2-3);

Das zweite war der Zeichensatz. Da wir aufgrund der unumstößlichen Bindung an unser Warenwirtschaftssystem auf Windows-Basis keinen kompletten Datenumstieg auf UTF-8 machen können (zumindest nicht zur Zeit), wird bei uns alles in latin1 gespeichert. Sollten wir mal über die europäischen Grenzen hinausexpandieren, dann können wir uns das ja immer noch zur Brust nehmen (dann haben wir aber sicherlich auch nicht mehr diese Warenwirtschaft).

Seit ein paar Versionen speichert nun mysqldum alles per UTF-8. Für ein komplettes Dump ist das auch wieder OK, denn im erzeugten Script sind die CREATE TABLE-Befehle ja mit dem Zeichensatz versehen und mysql weiß dann (hoffentlich), was es mit den INSERT-Datensätzen zu tun hat (nämlich mal kurz konvertieren!). Um einzelne Sätze in eine laufende Datenbank schnell per Copy&Paste zurückzuspielen, ist das aber unpassend. Hier hilft die Option –default-charset=latin1 weiter.

Mit diesen zwei kleinen Anpassungen kann ich nun die nächsten Backups in besserer Verfassung erwarten und gezielte Rückspielungen einfacher angehen. Nachdem das Raidsystem unseres jetzigen Webserver-Providers gerade krachte und wir quasi 48h ohne Online-Shop waren, weiß ich, dass Backups ihre Mühe wert sind.

CREATE TABLE IntraBerechtigungen (
  id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  Mitarbeiter varchar(255) NOT NULL,
  Seite varchar(255) NOT NULL,
  Lesen char(1) DEFAULT 'N',
  Ausfuehren char(1) DEFAULT 'N',
  Timestamp timestamp
);

Dann trägt man einfach seine Leute und die entsprechenden Seiten ein. Aber was passiert, wenn jemand neues hinzukommt? Wenn eine Seite hinzukommt oder wegfällt? Viel manuelle Arbeit. Mit Mustern wollte ich daher diese Mühe sparen.

Wenn man sich die mysql-System-Tabellen user oder db mal anschaut, findet man ja häufig Einträge wie “%” für den Host – d.h. hier ist der Zugriff von überall aus gestattet. Dasselbe könnte man hier auch anwenden, zB: Erlaube lesende Zugriffe für “%” auf die Seiten “CRM%.php”. Das würde die Tabelleneinträge in sinnvollem Maße begrenzen und mir erlauben, den Überblick zu behalten.

Der Unterschied zur normalen Mustersuche: Das Muster steckt sonst im PHP-Code, und die Strings in den Spalten der Tabellen. Hier steckt das Muster auf einmal in der Datenbank, aber die Strings im PHP-Code (zB als Benutzername irgendwo in $_SESSION). Das bedeutet leider auch, dass der herkömmliche SELECT

SELECT Lesen, Ausfuehren
FROM IntraBerechtigungen
WHERE ('Heinz' LIKE Mitarbeiter) AND ('/test.php' LIKE Seite);

nicht mehr funktioniert. MySQL meldet dabei, dass ‘Heinz’ und ‘/test.php’ keine validen Spaltennamen sind – womit es leider auch Recht hat.

Daher muss man die Konstruktion der Ergebnistabelle ein Stück vorziehen, indem man die Spalten zunächst konstruiert, und dann erst auswerten:

SELECT SUM(Lesen), SUM(Ausfuehren), 'Heinz' AS wer, '/test.php' AS was
FROM `IntraBerechtigungen`
WHERE EXISTS (
  SELECT *
  FROM IntraBerechtigungen
  WHERE (wer LIKE Mitarbeiter) AND (was LIKE Seite)
);

Damit die Überlagerung verschiedener Einträge (zB “%” darf “%.php” lesen, “Heinz” darf “%.php” lesen und ausführen) funktioniert, müssen allerdings die Felder Lesen und Ausführen auf INT(1) geändert werden. NULL oder 0 bedeutet verboten, 1 oder höher bedeutet erlaubt. Durch SUM(Lesen) kann man dann herausfinden, ob Nutzer “Heinz” in irgendeiner Form berechtigt ist, die Seite “/test.php” zu lesen oder auszuführen.

Auch Gruppenberechtigungen kann man damit abbilden. Dazu kann man in der Tabelle IntraBerechtigungen eine Spalte ‘Gruppe’ einführen, und die Nutzer, zB über ein simplen assoziativen Array in PHP, in Gruppen einteilen. *

$NUTZERGRUPPEN = array(
  'Heinz' => 'Sales',
  'Werner' => 'Sales',
  'Inge' => 'Verkauf'
);

* Es gibt ja immer wieder Leute, die meinen, so etwas muss man auch in MySQL abbilden, am besten in der 5. Normalform: id für die Gruppe, id für den Mitarbeiter, Verknüpfungstabelle, womöglich noch die Sprachabhängigen Attribute auslagern. Ich halte eine solche Grundeinstellung hochgefährlich für den laufenden Betrieb: Nicht nur die ids können bei einem Crash flöten gehen, auch die Verknüpfungstabellen in einer solchen zerpflückten Datenbank kann keiner mehr ohne Handbuch verstehen. Und statt den 20 Chars des Namen die immerhin 8 Bytes (64-bit-sicher!) INT für die id zu verwenden, spart 12 Byte. Erst kürzlich habe ich eine Platte von 400 GB für etwa 80 Euro erworben. Was sind da 12 Byte? Man spart diese Beträge durch schnellere Bearbeitung allemal. Abgesehen davon wäre für die Auflösung der Gruppenberechtigungen in einem solchen Fall ein Cross-Join über 3 Tabellen notwendig. Direkt in PHP getippt, spart man der DB wie auch dem Benutzer am Bildschirm wertvolle Zeit, indem man auf solche Schulbuchtechniken verzichtet.