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.

Gleichzeitig wollen wir aber zu jeder Zeit sicherstellen, dass wir das Model wie gewohnt vollständig abfragen und verwenden können. An dieser Stelle kommt eine Technik namens LazyLoading (lazy = engl. faul, träge) zum Einsatz.

Nun konstruiere ich einfach ein Beispiel, um den Ablauf besser erklären zu können. In unserer Anwendung brauchen wir ein Model “Person”, das Informationen wie Name, Geburtstag und diverse andere speichern kann. Den Namen und den Geburtstag brauchen wir immer (z.B. in der Listenansicht) und die restlichen Felder nur wenn wir eine Detailansicht erstellen.

Wie kommt unser Model nun an die Daten? In der Regel wird sicherlich load() auf dem Modelobjekt aufgerufen oder eine vergleichbare Methode auf der jeweiligen Collection, dann werden die Daten über ein Resourcemodel geladen und letztendlich komplett auf die einzelnen Modelobjekte kopiert.

Um unser Vorhaben umzusetzen müssen wir das etwas abändern. Die Methode load() des Models funktioniert wie gewohnt und lädt alle Daten und die Collection nur die Nötigsten. Um nun sicherzustellen, dass wir trotzdem immer alles abrufen können, muss das Model etwas intelligenter werden.

Die Entwicklung des Custom_Models hat der eine oder andere ja vielleicht mitbekommen und kennt den grundlegenden Aufbau. Relativ neu ist die Klasse Custom_Model_Persistent, durch die eine weitere Unterscheidung zwischen einfachen Datencontainern und speicherbaren Models möglich wird.

Für das automatische Nachladen muss die Modelklasse nun erweitert werden.

<?php
class Custom_Model_Persistent extends Custom_Model
{
  private $_isLoaded;

  // ...

  public function load($value = null, $field = 'id')
  {
    if (null === $value && $this->_isset($field)) {
      $value = $this->_get($field);
    }

    $this->getResource()
         ->loadModel($this, $value, $this->_mapKey($field))
         ->markLoaded();

    return $this;
  }

  public function isLoaded()
  {
    return $this->_isLoaded;
  }

  public function markLoaded()
  {
    $this->_isLoaded = true;
    return $this;
  }

  protected function _get($key, $default = null)
  {
    if (!$this->_isset($key) && !$this->isLoaded()) {
      $this->load();
    }
    return parent::_get($key, $default);
  }
}

Die entscheidenen Stellen sind hier der überschriebene zentrale Getter, der ein das “Default-Load()” auslöst, wenn der Wert nicht gesetzt ist und die Daten auch noch nicht vollständig geladen wurden und die Methode load() mit optionalen Parameter $value.

Im Beispiel verlasse ich mich darauf, dass das Standardfeld schon gesetzt ist. Eine ordentliche Fehlerbehandlung muss aber unbedingt her, wenn wir das ganze produktiv einsetzen wollen.

Die Methoden isLoaded() bzw markLoaded() sind absichtlich public, damit sie z.B. aus einer Collection aufgerufen werden können, wenn das Model komplett geladen wurde. Eine weitere Möglichkeit wäre ein Vergleich mit einer Liste die gesetzt sein sollten.

Im Moment ist das noch etwas im Entwurf und sogar ungetestet. Wenn euch nun noch was dazu einfällt, dann schreibt einen Kommentar. Wo seht ihr für euch die Vor- oder evtl. auch die Nachteile?

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!