Introduction

Object-relational mapping (ORM) frameworks have been around for several years now and for some people, ORM is already outdated by now. As we have seen with other technologies and concepts before, PHP is not exactly what we call an early adopter among the programming languages. Thus it took some time for ORM to grow up in the PHP context.

There have been some frameworks before Doctrine 2 that implement ORM (remember e.g. Propel) specific tasks but most of them lack the required maturity to be used in large projects. With Doctrine 2, PHP takes a huge step into the right direction – Doctrine 2 is fast, extensible and easy to use.

This article will take you on a tour through the main concepts of Doctrine 2 in the first part and then explain how to use it in a real world application in the second part. Since at the time of writing Zend Framework 1.11.xx (ZF) is very popular, we will integrate Doctrine 2 into a ZF project.

Basic Concepts

To understand Doctrine 2, we have to take a look at some relevant terms (or in this case objects), study their behavior and practice their usage. We start with some introductory phrases on ORM systems and then go on to the concepts underlying Doctrine 2: Entity Objects, the Entity Manager, Repositories and Proxies.

Object-relational Mapping

Since the beginning of Object-Orientation, people had to manage the persistence of their application's state resp. their objects. In the context of Web Application Development, this usually involves a Database server which is being consulted using a Query Language. One example for this pattern is a PHP application that uses some kind of SQL server by sending SQL queries to it. Another one is an application using a CouchDB server by querying it via its REST API.
Due to the author's laziness, we will talk in terms of relational databases from now on. Keep in mind, that you can accomplish almost everything mentioned here with NoSQL databases, too.

ORM relates value objects that exist in an application's business logic to database records. Thus every object that should be persistent is saved in one row of a database table. The most common approach is to map classes to tables and the classes' objects to rows in the these tables.
Besides writing objects to a database, ORM systems are also intended to ease the process of finding data stored in the database. When talking in terms of ORM, finding data always means making the framework fetch one or many objects that meet a certain criteria.

Entity Objects

The objects that are being managed by an ORM system are called Entity Objects. Every entity object relates to one entry in a table. In Doctrine 2, the classes that represent entities do not have to fulfill special requirements like inheriting from a certain super class (as you might have seen in other database abstraction frameworks like Zend_Db). When creating a new entity class with Doctrine 2, all you have to do is to write down a regular PHP class with properties. Besides this, you have to provide some hints on how these attributes should be persisted. The information how entity attributes relate to columns in the DB is called Metadata. Metadata can be described in different ways: By default there are metadata drivers for descriptions in XML, YAML and PHP. The fourth and most popular driver is based on DocBlock annotations (since in PHP, annotations aren't a language feature as in Java (see Wikipedia), they are contained by the classes' and attributes' DocBlocks). We will use annotations to describe our entities metadata. To get an impression on how easy this is, take a look at the following example.

This example contains all it needs to tell Doctrine 2 about the new entity User. With this class, you can create, find, delete and modify user objects and persist their state to the underlying database. But keep in mind: as long as you don't need any persistence features, you can use your user objects just like any other objects!

The next two objects resp. object types we will describe are responsible for doing the ORM functionality: persisting and finding.

The Entity Manager

To use ORM functionality, the Entity Manager (Doctrine\ORM\EntityManager) is the main access point to Doctrine 2. The entity manager is responsible – as you might have guessed – for managing entities and for building a facade for the whole framework. To accomplish its tasks, the entity manager uses some helpers. The Unit of Work object for example collects entities that should be written back to the database and is capable of doing this in batches. This way, database operation can be executed with almost no overhead and therefore are really fast.

Another dependency of the entity manager is the Event Manager. To be as extensible as possible, Doctrine 2 comes with an event system that publishes all important state changes to the outside as events. You can register for such events and extend the life cycle of your entity objects at one single point.

The entity manager's API combines methods for managing entities (find, persist, contains, copy, detatch, merge, remove and refresh), methods that control the use of transations (beginTransaction, commit, flush, rollback and transactional) and some helper methods for creating custom queries and accessing some of the entity manager's dependencies.

The following example shows how to query an object from the entity manager, modify it and write the changes back into the database.

Creating a new persistent object is almost as easy as modifying it:

Repositories

For finding entities, Repositories are used. Every entity class has its own repository which is responsible for finding entities of that type. By default, repositories have some handy methods for fetching entities that match certain criteria:

• find: Finds an entity by its primary key / identifier
• findAll: Finds all entities of the repository's entity type
• findBy / findOneBy: Finds all resp. one entity that matches the passed criteria:
  
• findBy<attribute> / findOneBy<attribute>: Magic methods that ease the filtering by a single attribute:
  

To access a repository, all you have to do is ask the entity manager for one. If you have implemented your own repository, it will be returned by Doctrine\ORM\EntityManager::getRepository(). Otherwise, Doctrine 2 will provide a generic repository. The main reason to implement custom repository classes is to group custom queries for an entity type to make them reusable. For custom query logic, there are several mechanisms you can use: You can either use Doctrine's query builder that implements an API similar to Zend_Db_Select or queries written in the Doctrine Query Language (DQL) or you can even execute plain SQL queries. With these options, it is also possible to migrate old applications which use complex queries by just wrapping these queries into the methods of custom repositories.

Proxies

When traversing a graph of entity objects (which is required when entities are having relations to other entities), it would be very expensive (in the sense of “requiring many database queries”) to fetch every depending entity with an additional query. Therefore Doctrine 2 uses the concept of Proxy objects that represent regular entity objects which have not been populated with data from the database. Take a look at the following example where the entity Group aggregates a list of User objects in its member property. When accessing the members list, Doctrine 2 provides a collection of proxy objects instead of complete User objects. When an object of this collection is being asked for one of its properties, Doctrine loads the object's data from the database. This way, the users' data is not loaded until it is really needed.

Advanced Mapping Concepts

This section describes some advanced concepts that are required when mapping entity classes that have relationships to other entity classes. Possible relationship types are association and inheritance. Inheritance is the mechanism used for representing subtypes in object-oriented programming languages. An example would be a class User that implements methods every user of a software should have and a class Administrator inheriting from User that adds methods for determining the administrator's access rights.

Association is a weaker relation type. It means that an entity object can be related to other entity objects of other types. In terms of relational databases, there are three types of association which differ in the number of entities an object is related to: 1:1, 1:n and n:m relationships. n and m are placeholders and mean multiple.

Association

To put objects of an entity type into relation, you just have to mention this relation in the entity class' mapping information. The simplest case is a unidirectional 1:1 relationship. In the following example we describe a User entity which has its access information (user credentials) encapsulated into another entity class called UserCredential. Since every user has at most one credential object and every credential object may only be associated to one user object, this is a 1:1 relationship.

If the relationship should be bidirectional, include the OneToOne attribute in the other class, too, and add an attribute which denotes the attribute of the other entity that mapps the related object:

This way, you can access the user object from the credentials object, too.
Most of the times, developers have to deal with relationships which include many objects on at least one side. These relationships are called 1:n or n:m relationships. This means that either one or multiple entities are standing in relationship with an arbitrary number of entities of another type. To accomplish this, you have to use the mapping keywords OneToMany or ManyToMany when describing your entities. Besides that, the mapping works the exact same way as with 1:1 relationships.

There are however some tricks you should know when dealing with collections of associated entity objects. Consider the following relationship between the entity classes User and Group:

When a group has at least one member, the group object will have a collection of the type Doctrine\Common\Collections\ArrayCollection set as its members property. This collection contains all user objects (or proxy objects as we have seen before) and can be modified intuitively with the methods add and removeElement. To honor object-orientation, you might want to introduce custom methods for these tasks. If you do so, you get into trouble when the group object does not have any users associated. In this case, the collection will simply be set to null. To avoid checks whether the collection has already be initialized, you should to this by yourself in the entity class' constructor:

It is also important to notice that one entity has to update the other entity's state as well when a relationship between to objects is created or removed. Take care to do this only in one class to avoid endless recursion loops! This class is called the Owning Side of the relationship. When implementing a bidirectional relationship, the other class is called the Inverse Side. It is important to determine owning and inverse side and implement the the classes accordingly to avoid greater trouble during debugging.

There are some more features implemented by Doctrine 2 enabling developers to specify their entities' relationships including sorting, pre-fetching and indexing. These topics are not covered in this article but are explained very understandable in the Doctrine 2 documentation.

Inheritance

Subtyping can be implemented in different ways using Doctrine 2. The main difference between these implementations is how the inheritance is mapped to the database. The options are to have one table for every class (Class Table Inheritance), to have one table for all classes in a hierarchy (Single Table Inheritance) and to have a table for every specialized sub-class of a given super-class (Mapped Super Class).We will give a short overview on all three alternatives, you have to pick the right one yourself. This decision should be made based on how many common attributes there are in your sub-classes.

Mapped Superclasses

Introducing a mapped superclass is probably the easiest way for specifying inheritance but might lead to many duplicate columns in your database schema. The superclass of your entities is not being declared as an entity itself (and might also be declared abstract) but provides attributes and optionally methods that will be available in all subclasses. When creating the database schema, Doctrine 2 merges all attributes and relationships of the superclass into the definitions of the subclasses and processes them as regular entities.

After creating the database from this mapping information, your tables will look like this:

Single Table Inheritance

When having entities that are very similar besides some few attributes, you might want to store them together in one database table. This approach is called Single Table Inheritance. To distinguish between the different types, there is always a column marked as discriminator column and a discriminator map that tells Doctrine 2 which values in the discriminator indicate what entity types.

These definitions cause the existing of one single table called User with all the attributes declared inside the classes User and Administrator plus a column type – the discriminator column. When working with entities of these types, Doctrine will manage the type flag automatically for you.

The resulting database schema looks as illustrated by the following diagram:

Class Table Inheritance

Having each entity type stored in its own table is always good for keeping your schema extensible. When you have to create a new subtype, Doctrine 2 will just create a new table for this type and it can inherit the logic and common attributes of a superclass. The only overhead you have with this approach is that all tables that correspond to subtypes have to maintain a relationship to their supertype's table. Using class table inheritance, the example with the entities User and Administrator looks like this:

Besides the inheritance type, there is no difference to the example using single table inheritance. The outcome on the resulting database scheme is huge. Now you have to separate tables which store users and administrators. Every record in the table Administrator has a corresponding record in the User table.

This was the first part of this article. Stay tuned for part II which will be published tomorrow (on 6th of December 2011)! In the second part, we will integrate Doctrine 2 into a Zend Framework application and include a generic sandbox (ZF-)project with Doctrine 2!

• ZCE PHP 5.3 – wäre ein schönes Update zu meinem ZCE PHP 5, für < 75 Euro würd ich drüber nachdenken, aber 195 Euro ist mir für das Update doch etwas zu viel
• ZCE-ZF die Zend Framework Zertifizierung. Da ich täglich mit dem Zend Framework arbeite ist das schon länger auf meiner Liste, aber da in wenigen Monaten (Schätzung von Matthew Weier O’Phinney ist April 2012) Version 2.0 erscheinen wird wollte ich noch darauf warten, sonst stehe ich bald vor dem selben Problem wie oben. Da gedulde ich mich noch ein wenig.
• Oracle Certified Professional, MySQL 5 Developer. Besteht aus 2 Prüfungen die jeweils 154 Euro kosten. Mit MySQL hat man auch fast jeden Tag zu tun.

Ich habe auf der Suche danach zwei Dinge gefunden: Eine 5 Tage MySQL for Developers Schulung für 2200 Euro und ein Certification Study Guide für 44 Euro.

Gibt es noch weitere interessante Zertifizierungen für einen Webentwickler die sich lohnen?

Hat jemand von euch schon die MySQL Prüfungen gemacht? Hat jemand von euch eventuell Lernmaterial, beispielsweise das oben genannte Buch günstig zu verkaufen?

Ähnliche Artikel:

1. Praxis-Workshop PHP Basics: Web-basierte Systeme mit PHP und MySQL
2. Zend Certified Engineer
3. ZCE Online Praxis Tests

Statt der .htpasswd können die Benutzerdaten auch in anderen Datenquellen stehen, z.B. einer MySQL Datenbank. Das kann dann sinnvoll sein, wenn man SVN und einen Bugtracker (z.B. Mantis, Redmine, Bugzilla oder auch Jira etc.) im Einsatz hat. In dem Fall kann dann die SVN-Benutzerverwaltung über die Daten des Bugtrackers abgedeckt werden.

Über verschiedene Module lassen sich wohl auch noch andere Datenquellen dafür nutzen. Bevor ich nun aber groß was dazu schreibe, verweise ich lieber auf SousGarden, denn dort ist es schon sehr anschaulich beschrieben. Eine Suchmaschine eurer Wahl bringt aber auch genug andere Treffer zu “mod_auth_mysql” oder “mod_auth_*”, wenn das nicht reicht oder eine andere Datenbank verwendet werden soll.

Weitere Information zur Verwendung finden sich auch noch hier. Sämtliche Anpassungen an der Apache-Konfiguration lassen sich auch in der .htaccess machen. Nun viel Spaß beim Probieren! Erfahrungsberichte bitte wie immer in den Kommentaren hinterlassen

Für dieses Mamut-Benchmarking habe ich die TestSuite von Roman Borschel [Benchmark of the major PHP ORMs] verwendet. Die TestSuite ist auch eine Art Benchmarking verschiedener ORM-Frameworks. Daraus habe ich mir jeweils das Benchmark für Doctrine2 und PDO rausgezogen und die Tests für meine Testzwecke erweitert. Anschließend habe ich ein neues Benchmark mit den nativen MySQL-Funktionen hinzugefügt. Das PDO- und das MySQL- Benchmark wurden als Active-Record implementiert.

Als Datenbank habe ich MySQL verwendet. Dort habe ich zwei Tabellen „Author“ und „Book“ mit einer 1:n Beziehung, Fremdschlüssel und Referenz-Optionen erstellt. Also ein Autor kann viele Bücher haben. Hier die Tabellendefinition und die SQL-Statements:

Author
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| firstName | varchar(128) | NO   |     | NULL    |                |
| lastName  | varchar(128) | NO   |     | NULL    |                |
| email     | varchar(128) | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

Book
+-----------+---------------+------+-----+---------+----------------+
| Field     | Type          | Null | Key | Default | Extra          |
+-----------+---------------+------+-----+---------+----------------+
| id        | int(11)       | NO   | PRI | NULL    | auto_increment |
| author_id | int(11)       | YES  | MUL | NULL    |                |
| title     | varchar(255)  | NO   |     | NULL    |                |
| isbn      | varchar(24)   | NO   |     | NULL    |                |
| price     | decimal(10,0) | NO   |     | NULL    |                |
+-----------+---------------+------+-----+---------+----------------+

Hier die CREATE TABLE Statements, die von Doctrine2 generiert werden.

CREATE TABLE `Author` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `firstName` varchar(128) NOT NULL,
  `lastName` varchar(128) NOT NULL,
  `email` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1701 DEFAULT CHARSET=utf8;

CREATE TABLE `Book` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `author_id` int(11) DEFAULT NULL,
  `title` varchar(255) NOT NULL,
  `isbn` varchar(24) NOT NULL,
  `price` decimal(10,0) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `IDX_6BD70C0FF675F31B` (`author_id`),
  CONSTRAINT `Book_ibfk_1` FOREIGN KEY (`author_id`) REFERENCES `Author` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1701 DEFAULT CHARSET=utf8;

Danach habe ich folgende Testszenarien definiert und pro Benchmark entsprechend umgesetzt:

Test-Szenario 1:
Erstellen eines Modell-Objekts, Setzen und Speichern von Attributen. Hier wurde
die Model-Objekt-Geschwindigkeit und die INSERT-Statement-Generierung gemessen. Je 1700 Mal ausgeführt

Test-Szenario 2:
Sucht einen Eintrag anhand des Primärschlüssels. Hier wurden das grundlegende Abfrage-Prinzip und die Objekt-Hydratation gemessen. Je 1700 Mal ausgeführt.

Test-Szenario 3:
Sucht einen Datensatz mit einer komplexen Abfrage. Hier wurde die Objektabfrage-Geschwindigkeit gemessen. Je 1900 Mal ausgeführt.

Test-Szenario 4:
Liefert fünf Datensätze für ein einfaches Kriterium, etwa Book.price=???. Hier wurde die Hydratations Geschwindigkeit gemessen. Je 190 Mal ausgeführt.

Test-Szenario 5:
Liefert einen Datensatz zusammen mit dem dazugehörigen Hydrat-Datensatz aus seiner Referenz-Tabelle. Hier wurde die Geschwindigkeit beim JOIN-Abfragen gemessen. Je 700 Mal ausgeführt.

Jede Abfrage-Möglichkeit wurde isoliert durch die oben beschriebenen Test-Szenarien ausgeführt. Dabei habe ich versucht, einen Zustand wie im Echt-Betrieb zu simulieren.

Testergebnisse und harte Fakten

1 Durchlauf zum aufwärmen:

             | insert | find   | complex| hydrate| join   |  memory MB
             |--------|--------|--------|--------|--------|----------------
   MySQL	  |    471 |    374 |    228 |    292 |    275 |     0.25559375
   PDO  	  |    495 |    369 |    220 |    312 |    276 |  0.30880859375
   Doctrine2 |    293 |   1260 |    298 |   1478 |    883 |  6.73025390625
             |--------|--------|--------|--------|--------|----------------

2 Durchlauf:

             | insert | find   | complex| hydrate| join   |  memory MB
             |--------|--------|--------|--------|--------|----------------
   MySQL     |    398 |    295 |    196 |    271 |    250 |     0.25559375
   PDO       |    454 |    336 |    205 |    285 |    269 |  0.30880859375
   Doctrine2 |    271 |   1110 |    291 |   1324 |   3390 |  6.67366796875
             |--------|--------|--------|--------|--------|----------------

3 Durchlauf:

             | insert | find   | complex| hydrate| join   |  memory MB
             |--------|--------|--------|--------|--------|----------------
   MySQL     |    411 |    304 |    202 |    275 |    244 |     0.25559375
   PDO       |    441 |    333 |    208 |    284 |    260 |  0.30880859375
   Doctrine2 |    276 |   1158 |    297 |   1341 |    839 |  6.73586328125
             |--------|--------|--------|--------|--------|----------------

Hier die jeweiligen SQL-Statements in abgekürzter Form, um sehen zu können, was die obigen Test-Probanden an SQL im Hintergrund erzeugen

SQL-Statements erstellt von MySQL während des Benchmarks
SQL-Statements erstellt von PDO während des Benchmarks
SQL-Statements erstellt von Doctrine2 während des Benchmarks

Erkenntnisse

Für die unten aufgeführten Erkenntnisse habe ich mich mehr auf Doctrine2 beschränkt.

INSERT-Statements

Alle INSERT-Statements werden immer gebündelt und gemeinsam in einer Transaktion ausgeführt. Man bekommt hierfür in etwa ein Gefühl dafür, wie die Geschwindigkeit sich bei einem Massen-Import verhält

Suche anhand des Primärschlüssels

Ohne es mit einen nativen PHP-MySql Abfrage-Art zu vergleichen, möchte ich behaupten, dass Doctrin2 langsamer ist. Hier haben wir jedoch ein ORM mit viel Abstraktion. Letztendlich ging das Abfragen mit DOctrine2 ganz bequem und das erwartete Reslut-Objekt wurde ausgeliefert. Doctrine2 bietet mehrere Möglichkeiten für das Ausliefern eines Abfrage-Ergebnisses: Als Modell-Objekt, als Array-Hydrat, als Scalar-Hydrat, als Modell-Objekt mit Verwendung des internen Array-Cache, als Modell-Objekt ohne Verwendung der internen Proxy-Klassen (zuständig für das Überladen) und als Iterator-Hydrat.

Suche anhand einer komplexen Abfrage

Hierfür wurde ein Statement mit Bedingungen WHERE+OR+CONCAT kombiniert verwendet. Die Suchergebnisse wurden ebenfalls schnell ausgeliefert. Dieselbe Abfrage mitunter Verwendung des internen Array-Cache war wie erwartet – schneller.

Auslieferung von Suchergebnissen als nicht Doctrine2-Model-Objekte

Wie oben im Text beschrieben, können die Suchergebnisse als Array oder Scalar-Object ausgeliefert werden. Diese können wiederum mit Verwendung vom internen Caching optional mitArray, Memory oder APC ausgeführt werden. Zudem hat man die Möglichkeit, das Ausliefern der Suchergebnisse ohne das interne Überladen (lazy-loading) durchzuführen. Diese Möglichkeit (also lazy-loading, überschreiben) sollte man jedoch auslassen, da sich die ausgelieferten Objektmodelle instabil zu ihren Entitäten verhalten können. Nichtsdestotrotz, alle drei Kombinationen haben sich als ähnlich schnell erwiesen, nur bei den JOIN-Statements war ein kleiner, jedoch unwesentlicher, Unterschied zu vermerken.

Caching und Cache-Validation

Doctrine2 bringt mehrere Caching Mechanismen: APC, Memcache, Xcache und ArrayCache. Es bietet die gängigen Caching Operationen. Das Finden und Löschen kann nach Angabe eines Suffixes, Präfixes, Regulären-Ausdrucks und Namespaces erfolgen. Es werden also viele Möglichkeiten geboten, nach bestimmten Kriterien eine Gruppe aus dem Cache zu identifizieren und oder sie zu löschen.

Hierfür habe ich einen ganz einfachen Test ausgeführt:

1. Gib mir das Modellobjekt aus dem Repository mit der id=1
2. Speichere diese in den Cache unter der cacheId=cache_id123 für 3sek.
3. Hole das Modell-Objekt aus dem Cache und vergleiche es mit dem Model-Oobjekt aus dem Repository.
4. Halte den Prozess für vier Sekunden an und versuche, das Objekt aus dem Cache zu laden.

Hier die Ausgabe in der Konsole:

---------- Repository before Cache ----------
Attribute: 1 color blue
Attribute: 1 name dog
Content: hallo wie geht es dir?
---------- Repository == Cache -------------
bool(false)
---------- Repository ---------------------
Attribute: 1 color blue
Attribute: 1 name dog
Content: hallo wie geht es dir?
---------- Cache --------------------------
Attribute: 1 color blue
Attribute: 1 name dog
Content: hallo wie geht es dir?
---------- Sleep 4sec, get data Cache ------
bool(false)

Beide Objekte sind von derselben Instanz und haben denselben Inhalt, werden jedoch nicht als gleich identifiziert. Doctrin2 biete also das gängige Caching-Verhalten und sorgt nicht dafür, dass auch die Objekte im Cache konsistent zur Datenbank bleiben.

Weitere und detaillierte Information über den Cache gibt es hier: http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html

Massen Inserts & Massen Object Processing

Doctrine2 unterstützt keine multi-INSERTs wie „(insert into (…) values (…), (…), (…),..“. Dafür werden die INSERT-Statements jeweils einzeln ausgeführt. Laut Doctrine2 soll das perfomanter sein. Zudem sind die Single-INSERT-Statements für Doctrine2 leichter in anderen DB-Systemen zu übertragen, als multi-INSERT-Statements. Für eine initiale Massen-Migration ist das Doctrine2 eher nicht gedacht. Jedoch bietet es eine Art von “Batch Processing”. Damit ist es möglich, die Massen-Migration von Daten in fest definierten Chargen abzuarbeiten bzw. in die Datenbank zu migrieren. Die Ausführungszeiten und der Speicherverbrauch sind mehr als akzeptabel. Wenn man oft mit sehr vielen Daten arbeiten muss, dann gibt es die Möglichkeit, sich die Daten als “Iterable-Result” ausliefern zu lassen und darüber zu iterieren. In diesem Fall ist das schneller, als wenn man sich die Daten als Hydrat-Objekt ausliefern lässt. Wem das aber immer noch nicht schnell genug ist, dem rät Doctrine2, interne Datenbank-Optionen für Massen-Importe zu verwenden. Wie bei MySQL “LOAD DATA INFILE”.

Mehr Information und einen ausführlichen Bericht hier:
-http://www.doctrine-project.org/blog/doctrine2-batch-processing
-http://www.doctrine-project.org/docs/orm/2.0/en/reference/batch-processing.html

Arbeiten mit nicht relationalen Datenbanken

Der Vorteil von NoSQL Datenbanken gegenüber MySQL oder jeder anderen RDBMS ist ganz klar die Performance. Für Doctrine2 gibt es PlungIns auf GitHub zum Herunterladen. Diese können laut Dokumentation auch alle gängigen Entitäten abbilden. Der Unterschied liegt in der Deklaration der Annotationen in den Modell-Klassen. Für ein Umsteigen von SQL auf NoSQL Datenbank ist also eine umfassende Anpassung an der Projekt-Konfiguration und der Modell-Klasse notwendig. Abfrage-Methoden wie find*(…) oder getRepository(…) müssen nicht angepasst werden.

Mehr Information:
- http://www.doctrine-project.org/docs/mongodb_odm/1.0/en/index.html
- http://www.doctrine-project.org/blog/mongodb-for-ecommerce
- http://www.doctrine-project.org/docs/couchdb_odm/1.0/en/index.html
- mongodb-odm https://github.com/doctrine/mongodb-odm
- couchdb-odm https://github.com/doctrine/couchdb-odm

Erstellen von Custom Mapping Types

In Doctrine2 ist es möglich, auch eigene Spalten-Typen zu definieren. Ich habe es mit dem Typ “email” getestet. Dafür muss im Projekt ein neues Verzeichnis “Types” erstellt werden. In der Konfigurationsdatei muss der neue Typ bekannt gemacht werden:

//...
use Doctrine\DBAL\Types\Type;
//...
Type::addType('email', 'Types\Email');
//...
$conn = $em->getConnection();
$conn->getDatabasePlatform()->registerDoctrineTypeMapping('email', 'email');

Und so sieht die Klasse des neuen email-Types aus. Eine einfache E-Mail-Validierung ist auch eingebaut.

namespace Types;
use Doctrine\DBAL\Types\ConversionException,
    Doctrine\DBAL\Types\Type,
    Doctrine\DBAL\Platforms\AbstractPlatform;
class Email extends Type
{
    const MYTYPE = 'email';
    /** @override */
    public function convertToDatabaseValue($value, \Doctrine\DBAL\Platforms\AbstractPlatform $platform)
    {
      if (false === filter_var($value, FILTER_VALIDATE_EMAIL))
      {
        throw ConversionException::conversionFailed($value, $this->getName());
      }
      return $value;
    }
    /** @override */
    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
      return $platform->getVarcharTypeDeclarationSQL($fieldDeclaration);
    }
    /** @override */
    public function getDefaultLength(AbstractPlatform $platform)
    {
      return $platform->getVarcharDefaultLength();
    }
    public function getName()
    {
        return self::MYTYPE;
    }
}

Nach dem Setup, wurde die Tabelle Author wie erartet ohne Probleme erweitert und gültige E-Mails konnten abgespeichert werden.

Alle Features in einer Tabelle

Prepared Statements: bei der MySQL Lösung muss man leider selber Methoden schreiben, um Prepared Statements ausführen zu können. PDO und DOctrine2 bringen das von Haus aus mit.

Transactions: alle Test-Probanden unterstützen das. Wobei bei MySQL die Methoden erst geschrieben werden müssen. Lustig wird das bei Nested-Transactions. Doctrine2 kann das, für PDO und MySQL muss das implementiert werden.

Caching: bei dem MySQL- und PDO-Probanden muss das Caching implementiert werden, Doctrine2 hingegen bringt das mit von Haus aus mit.

Mass insert: das unterstützen alle drei Probanden.

Exceptions: bei MySQL muss man die Exceptions implementieren. PDO und Doctrine2 bringen diese von Haus aus mit.

Object Hydration: alle drei Probanden können ein Result-Set als Object zurückliefen. Doctrine2 kann jedoch noch mehr: als Array-Object, Iretable-Object und Model-Object.

Scaffolding: bei den MySQL- und PDO-Probanden muss das erst implementiert werden, Doctrine2 bringt das von Haus aus mit.

Reverse Engineering: nur der Doctrin2-Proband kann das. Ein paar mögliche Operationen wären: SQL-Datei in die Datenbank importieren, internes Caching Operationen, konvertieren von diversen Datenbank-Shema ins PHP, Model- und Mapper-Klassen aus der Datenbank generieren.

Drivers: bei MySQL ist es klar, nur MySQL Datenbank. PDO kann viele SQL basierende Datenbanksysteme unterstützen. Bei Doctrine2 ist es genauso wie bei PDO, da es auf PDO basisiert. Für Doctrine2 gibt es zusätzlich noch Driver als Add-ons, die MongoDB oder CouchDB unterstützen.

Gedanke

Wenn ein Team zum ersten mal mit Modellen/Objekten arbeiten möchte, dann sollte es sich zuerst mit dem Active-Record-Pattern gut vertraut machen. Ist auch leicht zum umsetzen, kontrollieren, erweitern, optimieren und debuggen. Ein typisches ORM hingegen basiert auf das Repository-Pattern. Dieses macht viel Magie unter der Haube. Ist daher nicht einfach zu kontrollieren und debuggen. Man macht sich von ein ORM abhängig. Mann muss das ORM auch nicht komplett verwenden. Es reicht oft auch, wenn man nur das manipulieren der Datenbank dem ORM überlässt. Bei diesem Punkt möchte ich es nicht verallgemeinern, den der genaue Einsatz eines ORM hängt von der Anforderung des Projektes und Teams ab.

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.

Warum NoSQL?

NoSQL ist zu einem Oberbegriff von Datenbanksystemen geworden, die weit mehr Eigenschaften haben als nur der Verzicht auf SQL als Abfragesprache. Ich denke, die Eckdaten der am meisten verbreiteten Systeme sind klar:

• Hohe horizontale Skalierbarkeit (horizontal=viele Rechner, vertikal=ein großes, schnelles System)
• Eingeschränkte Verknüpfungen von Datensätzen untereinander (JOIN)
• Keine Tabellen, in die die Daten gezwängt werden
• Kein SQL als Abfragesprache

Warum aber NoSQL?

Warum soll man sich neuer Technik bedienen, wenn die Alte (Technik!) doch bislang immer funktioniert hat ?
Der Grund “weil’s Spaß macht” ist aus Entwicklersicht einsichtig, aus betriebswirtschaftlicher Sicht eher weniger.
Wer sich die gängigen NoSQL-Beispiele ansieht, kommt recht schnell auf die Idee, daß anscheinend außer Blogs nicht viel mehr mit NoSQL gemacht werden kann. Macht es Sinn, eine relational funktionierende Produktdatenbank mit den NoSQL-Features umzusetzen?

Aus Jux und dollerei wird kaum jemand ein bestehendes Projekt auf die neue Technologie umändern. Ist auch nicht immer nötig, aber wie wäre es damit, Teile zu ersetzen?

Eine Produktdatenbank hat immer zwei Zugriffszenarien: Die Daten werden erstellt, oder gelesen. Anders als bei Twitter und Co sind die Zugriffszahlen beim Lesen immens höher als beim Schreiben. Und was macht SQL? Um dem Kunden Die passenden Produkte anzuzeugen, geht dem meist ein Wust an JOINS voraus. Tabellen mit Fahrzeuginformationen, Produktstamm, Eigenschaften in Abhängigkeit vom Fahrzeugen, Preistabellen, Sperrungen und Abhängigkeiten von anderen Produkten… all das wird einmal erstellt, aber tausendfach abgerufen. Zur Optimierung der Zugriffszeiten beim Lesen müssen Cachingmechanismen herhalten.

Speicher ist billig, Zeit ist teuer.. und da kommen die Schemalosen Datenbanken ins Spiel. So kann, nachdem ein Produkt angelegt und mit seinen Eigenschaften versehen ist, dieses Produkt mit all seinen Eigenschaften und Abhängigkeiten einfach als Dokument in eine NoSQL Datenbank gespeichert werden. Dass nun jedes Produkt auch alle passenden Fahrzeuge beinhaltet (und damit die Fahrzeuge hundertfach in den Produkten vorkommen) ist aus Normierungssicht horrend redundant. Aber aus zeitlicher Sicht ist eine 10000-fache JOIN-Orgie gegenüber einer einmaligen Zusammenstellung aller Daten zu einem Produktdokument ebenso redundant.

Es ist also ein kleiner erster Schritt, die vorhandenen relationalen Daten in einem Exportvorgang zusammenzufassen und als Dokumente in eine Schmalose Datenbank zu packen.

Die Wahl fiel bei uns auf die CouchDB, da sie den Gedanken der Geschwindigkeitsoptimierung beim lesen vor dem des Schreibens durch vordefinierte Abfragen konsequent umsetzt.

Ich werde Ihnen in regelmäßigen Abständen die Ideen und Hürden hinter dieser Umsetzung nahe bringen.