mysqldump datenbank_orig > datenbank_orig.sql -ubenutzername -p

Neue Datenbank aus Datei befüllen:

mysql -ubenutzername -p datenbank_kopie < datenbank_orig.sql

Hier ein kleiner Spickzettel, wie sich die Doubletten wieder entfernen lassen.

Die Struktur der Testtabelle sieht folgendermaßen aus:

CREATE TABLE `sqltest`.`duplicates` (
  `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  `a` VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `b` INT(11) NOT NULL ,
  `c` DATETIME NOT NULL ,
PRIMARY KEY (`id`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci;

Noch ein paar Daten rein und fertig ist die Spielwiese.

mysql> select * from duplicates;
+----+--------+-----+---------------------+
| id | a      | b   | c                   |
+----+--------+-----+---------------------+
|  1 | Apfel  | 123 | 2011-01-11 17:00:00 |
|  2 | Apfel  | 123 | 2011-01-11 17:00:00 |
|  3 | Banane | 234 | 2011-01-12 17:00:00 |
|  4 | Banane | 234 | 2011-01-12 17:00:00 |
|  5 | Birne  | 456 | 2011-01-15 17:00:00 |
|  6 | Birne  | 456 | 2011-01-15 17:00:00 |
+----+--------+-----+---------------------+
6 rows in set (0.00 sec)

Die erste Abfrage macht einen JOIN auf sich selbst, dafür die Aliasse d1 und d2 und dient zunächst der Prüfung, ob wir die gewünschten Datensätze geliefert bekommen.

SELECT d1.* FROM duplicates d1, duplicates d2
 WHERE d1.id != d2.id
   AND d1.a = d2.a
   AND d1.b = d2.b
   AND d1.c = d2.c
   AND d1.id < d2.id

Das Ergebnis:

+----+--------+-----+---------------------+
| id | a      | b   | c                   |
+----+--------+-----+---------------------+
|  1 | Apfel  | 123 | 2011-01-11 17:00:00 |
|  3 | Banane | 234 | 2011-01-12 17:00:00 |
|  5 | Birne  | 456 | 2011-01-15 17:00:00 |
+----+--------+-----+---------------------+
3 rows in set (0.00 sec)

MySQL kann offensichtlich keine Daten löschen, wenn die Löschaktion auf derselben Tabelle wie die Subquery gemacht wird. Darum schreiben wir die Ids in eine temporäre Tabelle.

CREATE TABLE duplicates_ids AS (
  SELECT d2.id FROM duplicates d1, duplicates d2
   WHERE d1.id != d2.id
     AND d1.a = d2.a
     AND d1.b = d2.b
     AND d1.c = d2.c
     AND d1.id < d2.id
)

Im letzten Schritt löschen wir die zuvor ausgewählten Datensätze und auch die temporäre Tabelle. Je nachdem was wir behalten wollen, noch ggf. ein “NOT” vor das “IN” schreiben.

DELETE FROM duplicates WHERE id [NOT] IN (SELECT * FROM duplicates_ids);
DROP TABLE duplicates_ids;

Achtung! Ich hafte nicht bei Datenverlust oder sonstigen Fehlern. Ein Backup sollte sicherheitshalber vorher gemacht werden.

CREATE TABLE `mails` (
  `id` int(11) NOT NULL auto_increment,
  `parent_id` int(11) NOT NULL,
  `addy` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Jede Emailadresse hat eine Id und eine ParentId. Sind beide Ids identisch, dann ist es die Originaladresse, ansonsten ein Alias.

mysql> select * from mails;
+----+-----------+------------------+
| id | parent_id | addy             |
+----+-----------+------------------+
|  1 |         1 | m1@example.com   |
|  2 |         1 | a1m1@example.com |
|  3 |         3 | m2@example.com   |
|  4 |         1 | a2m1@example.com |
|  5 |         3 | a1m2@example.com |
+----+-----------+------------------+
5 rows in set (0.00 sec)

Mit einem selbstreferenzierenden Join werden die Daten nun wieder aus der Tabelle ausgelesen. Dabei wird die Tabelle ‘mails’ durch Aliasnamen wie zwei Tabellen behandelt. Wir selektieren die ‘addy’ aus der Tabelle ‘m1′ und die gejointen Aliase aus ‘m2′. Durch GROUP_CONCAT() werden die Werte nun kommasepariert in der Spalte ‘aliases’ ausgegeben.

mysql> SELECT m1.addy, GROUP_CONCAT(m2.addy SEPARATOR ', ') AS aliases
 ->   FROM mails m1
 ->   JOIN mails m2 ON m2.parent_id = m1.id
 ->  WHERE m2.id <> m2.parent_id
 ->  GROUP BY m1.id;
+----------------+--------------------------------------+
| addy           | aliases                              |
+----------------+--------------------------------------+
| m1@example.com | a1m1@example.com, a2m1@example.com   |
| m2@example.com | a1m2@example.com                     |
+----------------+--------------------------------------+
2 rows in set (0.00 sec)

Das funktioniert natürlich auch mit den Ids der Alias-Adressen. In diesem Fall muss dann aber der Rückgabewert von GROUP_CONCAT() gecastet werden, da sonst entweder nur die erste Id oder [BLOB] in der Ausgabe stehen würde.

mysql> SELECT m1.addy,
 ->           CAST(GROUP_CONCAT(m2.id SEPARATOR ', ') AS char) AS alias_ids
 ->   FROM mails m1
 ->   JOIN mails m2 ON m2.parent_id = m1.id
 ->  WHERE m2.id <> m2.parent_id
 ->  GROUP BY m1.id;
+----------------+-----------+
| addy           | alias_ids |
+----------------+-----------+
| m1@example.com | 2, 4      |
| m2@example.com | 5         |
+----------------+-----------+
2 rows in set (0.00 sec)

Die Funktion kann nicht nur gruppieren und mit beliebigen Trennzeichen aufzählen, es ist auch möglich, eine Sortierrichtung mit anzugeben. Mehr dazu im MySQL-Manual.

The total number of locks exceeds the lock table size

Nach kurzem googlen fand ich den Artikel von Cyril, der offensichtlich die selben Schwierigkeiten hatte.

Die Lösung war zum Glück recht einfach. In der Datei my.cnf muss der folgende Wert erhöht werden, bzw. die Konfigurationseinstellung hinzugefügt werden.

innodb_buffer_pool_size = 16M

Die neue Einstellung sollte dann die Arbeit mit der großen Tabelle ermöglichen.

innodb_buffer_pool_size = 268435456

Zum Schluss dann noch den MySQL-Server neu starten, damit die Änderungen auch wirksam werden.

Die Anbindung an eine (PHP-)Anwendung ist bei den Voraussetzungen nun denkbar einfach. Aber eins nach dem anderen.

Was macht CouchDB denn aber nun zu einer “bequemen” Datenbank? Eigentlich fast alles. CouchDB arbeitet mit Dokumenten und eignet sich dadurch besonders für variable Strukturen und jegliche Daten, die eigentlich nicht in eine relationale Datenbank passen und nur mit viel Mühe geschrieben und gelesen werden können.

In RDBM-Systemen werden derartige Daten im besten Fall im EAV-Datenbankmodel (EAV = Entity-Attribute-Value) abgelegt. Das ist nicht nur sehr CPU-lastig, sondern auch für Menschen schwer bis garnicht lesbar. In CouchDB-Dokumenten liegen die Daten quasi im Stück vor, sind schnell geladen und können auch über Futon einfach bearbeitet werden.

Eigentlich macht alles einen sehr einfachen und leichten Eindruck. Die Installation dauerte mit ein paar Einstellungen nicht länger als zehn Minuten und das System war zumindest als Entwicklungsserver einsatzbereit. Das Admintool Futon und die REST-API sind unter “http://localhost:5984″ direkt nach dem Start verfügbar.

Futon überrascht mit einer eher schlichten Oberfläche ohne unnötigen Schnickschnack, bietet aber alles Nötige, um damit arbeiten zu können.

Die Verbindung aus der PHP-Anwendung heraus habe ich mit Zend_Http_Client umgesetzt, es funktioniert aber auch mit curl oder anderen HTTP-Clients. Die Daten werden im JSON-Format gelesen und auch wieder geschrieben, daher lassen sich auch komplexere Strukturen einfach mit json_encode() und json_decode() verarbeiten.

Im Gespräch mit einem bekannten Entwickler bekam ich die Antwort, CouchDB sei doch nur ein einfacher Key-Value-Speicher und nicht mächtig genug.

Dem ersten Punkt möchte ich nicht widersprechen. Grob betrachtet haben wir einen Key-Value-Speicher, der jedoch durch seine Views die Daten in beliebiger Form zusammenstellen kann (habe ich eigentlich schon erwähnt, dass die Views mit einfachen JavaScript funktionieren?). Und gegen einfach ist aus meiner Sicht auch garnichts einzuwänden. Warum sollte man auch ein Tool nutzen wollen, welches die Arbeit komplizierter statt einfacher macht?

Fazit: Auch Zahnarztfrauen, ähm… Möbelhändler empfehlen CouchDB!

mysqldump -u[USERNAME] -p[PASSWORD] -r path/to/dumpfile.sql --databases [DATABASENAME]

Dump einspielen

mysql -u[USERNAME] -p[PASSWORD] < path/to/dumpfile.sql

oder auch mit mysqlimport.

Die meisten PHP-Programmierer, sofern sie nicht auf einem Linux-System mit grafischer Oberfläche arbeiten, werden das Problem sicherlich gut kennen.

Wenn man nur einen Rechner zur Verfügung hat und alle Dienste unter Windows laufen entspricht das sicherlich nicht unserem Live-System und wir können nicht alles zuverlässig testen und sind auch sonst an vielen Stellen eingeschränkt in unserer Arbeit. Zudem laufen die Dienste in der Regel immer mit an, auch wenn wir nicht Programmieren wollen und verbrauchen dann unnötig Rechenleistung.

Die zweite Möglichkeit wäre dann noch ein zweiter Entwicklungsrechner, auf dem wir ein Linux installieren und dann über das Netzwerk arbeiten. Das würde uns einen weiteren Rechner und natürlich auch noch Strom kosten. Selbst wenn dieser Entwicklungsserver von einem ganzen Team genutzt würde, besteht immernoch die Gefahr, das eine Mitarbeiter die Kiste aus Versehen in die Knie zwingt.

Durch die Arbeit mit der Virtuellen Box (oder vergleichbaren Programmen) kann nun jeder Entwickler auf seinem Windows gleichzeitig auch ein Linux-System zur Verfügung haben und dessen Vorteile nutzen (z.B. SymLinks, Cronjobs).

Einmal installierte und konfigurierte Systeme lassen sich exportieren und wieder an andere Verteilen, so dass eine einheitliche und dennoch individuelle Entwicklung möglich ist. Die Zeitersparnis beim Aufsetzen eines neues Entwicklungsrechners ist dabei enorm.

Die Gastsysteme können nach der Installation gewöhnlich wie jeder andere Rechner im Netzwerk angesprochen werden, d.h. wir könnten unsere PHP-Dateien mit FTP hochladen oder einfach eine Samba-Freigabe unseres virtuellen Servers nutzen.

Auf die einzelnen Schritte der Installation gehe ich in diesem Artikel nicht ein, könnte das aber bei ausreichenden Interesse für einen weiteren Artikel einplanen.

Meine Installation basiert auf einem Debian-Linux. Die Konfiguration beinhaltet neben den typischen LAMP-Komponenten (Apache2, MySQL und PHP5), u.A. Samba für die Netzwerkfreigabe, einen SSH-Server, um mit PuTTY darauf arbeiten zu können, PEAR, PHP-CodeSniffer, PHPUnit, Apache Ant, sowie phpMyAdmin und verschiedene Zend Framework Versionen.

Das exportierte Image ist dabei mit 734 MB klein genug, dass es auf einer CD oder einem USB-Stick weitergeben werden kann.

Die Technik der Virtualisierung ist nicht neu, aber ich denke, es ist eine gute und vor allem kostengünstige Alternative zu den anderen genannten Möglichkeiten.