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.

$image = 'bild.jpg'; $mimeType = mime_content_type($image); $content = file_get_contents($image); $url = 'http://developer:5984/database/document/path?rev=xx-xxxxx'; $client = new Zend_Http_Client(); $response = $client->setUri($url) ->setMethod('PUT') ->setHeaders(array('Content-Type' => $mimeType)) ->setRawData($content, $mimeType) ->request() 

Die Anhänge könnten auch mit dem Dokument im JSON-Format übertragen werden. Dafür müsste $content dann aber erst base64_encoded werden. Hierbei werden bestehende Anhänge aber gelöscht!

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!

Die Underscore-Schreibart (z.B. “user_id”) findet man sehr oft als Spaltenbezeichner in Datenbanken oder auch in XML-Dateien, im PHP-Model (siehe auch mein Artikel zum Custom_Model) hingegen wird oft CamelCase (z.B. “userId”) verwendet.

Es wird also an der Schnittstelle zwischen dem Model und der Datenquelle eine Art Key-Mapping benötigt. Das lässt sich zwar recht einfach mit regulären Ausdrücken erschlagen, aber man kann sich auch der Zend_Filter-Klassen bedienen, wenn man in einem ZF-Umfeld arbeitet.

Die Anwendung ist wie so vieles beim Zend Framework recht einfach:

<?php
$toCamelCaseFilter = new Zend_Filter_Word_UnderscoreToCamelCase();
echo $toCamelCaseFilter->filter('user_id');

// Ausgabe: UserId

Umgekehrt, wen wird es wundern, ist das natürlich genauso leicht:

<?php
$toUnderscoreFilter = new Zend_Filter_Word_CamelCaseToUnderscore();
echo $toUnderscoreFilter->filter('UserId');

// Ausgabe: User_Id

Wenn man nicht extra eine Instanz erzeugen will, dann lassen sich die Zend Filter auch mit einem statischen Aufruf nutzen.

<?php
echo Zend_Filter::filterStatic('bitte_einmal_camel_case',
                               'Word_UnderscoreToCamelCase');

// Ausgabe: BitteEinmalCamelCase

Das war es dann auch schon wieder für heute. Ich hoffe, dass euch der Artikel gefallen hat und ihr viele kreative Ideen zum Arbeiten mit den Filtern habt.