PHPGangsta - Der praktische PHP Blog

Ein Gastbeitrag von Tim Glabisch
Junger Software und Webentwickler aus Düsseldorf, Vollzeit bei anyMOTION Graphics GmbH und auf jedem Treffen der PHP UG Düsseldorf dabei.

Wir haben regelmäßig die interessante Aufgabe, für Kunden Content Management Systeme zu evaluieren. Typische Vertreter, welche wir eingesetzt haben, sind Drupal, TYPO3 4.x, WordPress und viele weitere.

Daraufhin bin ich tief in mich gegangen und habe mich gefragt, was mich an den Lösungen stört, welche mir bis zu diesem Zeitpunkt bekannt waren. Ich überlegte mir ganz genau was ein CMS für mich erfüllen muss, damit ich effektiv und gerne damit arbeiten kann.
Weiterlesen »

Heute kam mir eine nette kleine Programmieraufgabe zu Ohren, und da dachte ich gleich an euch. Das könnte eine interessante Aufgabe sein um zu zeigen wie mit unterschiedlichen Vorgehensweisen das Problem gelöst werden kann.

Die Aufgabe: Die Zahlen 1 bis 10.000 sollen der Reihe nach ausgeschrieben werden, getrennt durch einen Umbruch. So sieht die Ausgabe dann aus:

eins
zwei
drei
vier
fünf
......
eintausendzweihundertdreizehn
eintausendzweihundertvierzehn
....
zehntausend

Ich hoffe die Aufgabe ist verständlich. Mich würde vor allem die Codelänge interessieren, ich glaube die Laufzeit oder Speicherverbrauch sind relativ uninteressant bzw. sehr ähnlich.

Programmiersprachen: Natürlich PHP, aber auch gern andere Sprachen zum Vergleich.

Edit: Eine sehr schöne Zusammenfassung der Ergebnisse hat Rodney Rehm geschrieben, Danke!

UPDATE: Auch 2011 habe ich wieder ElePHPanten im Angebot.

Durch einen glücklichen Zufall habe ich jemanden aus den Niederlanden kennengelernt, der noch einige elePHPanten zu verkaufen hatte. Wer einen zu Weihnachten verschenken möchte, an Arbeitskollegen, Ehemänner/-frauen, Bekannte, Freunde oder auch sich selbst, möge sich unten in den Kommentaren einreihen, und weiterlesen. Oder gebt diese URL an andere weitere und lasst euch einen schenken 😉

Die elePHPanten sind sehr rar, und ich habe mich dieses Jahr durch unzählige Foren, Blogs und Shops gekämpft und niemand wußte wo man welche kaufen kann. Meinen ersten ElePHPanten habe ich dieses Jahr auf der phpunconference erstanden. Die wenigen Shops die sie verkaufen haben auf Email-Anfragen alle sagen müssen dass ihre Lager leer sind. Auch der Hersteller Nexen aus Frankreich hat keine mehr, Damien Seguy vertröstete mich auf nächstes Jahr.

Was müßt ihr tun? Ganz einfach, es gibt 2 Möglichkeiten:

– Ihr schreibt einen tollen Gast-Artikel mit mindestens 800 Worten über ein interessantes PHP-Thema und verdient euch damit einen ElePHPanten

– Ihr überweist mir 14 Euro

Auf jeden Fall erstmal einen Kommentar hinterlassen, damit wir die Reihenfolge festlegen können. Dann schreibt ihr mir eine Email an  mit einem Themenvorschlag oder eurer Adresse.

Ich habe übrigens mehr als 20, je nachdem wie hoch die Nachfrage ist würde ich die Menge auf einen ElePHPanten pro Person beschränken, damit möglichst viele einen bekommen.

Hier einige tolle Bilder des elePHPanten auf Flickr:
http://www.flickr.com/search/?q=elephpant

Oder Googles Bildersuche:
http://www.google.de/images?q=elephpant

Ein Gastbeitrag von Florian Heinze, Gründer von vsChart.

Für alle die sich fragen, NoSQL – was ist das und wie geht das überhaupt, folgend ein praktischer Einstieg am Beispiel von MongoDB.

Zunächst, was bezeichnet genau NoSQL? Der Begriff ist etwas unglücklich. Denn es geht nicht um die Ablehnung der Abfragesprache SQL, sondern um die Befürwortung von Alternativen zu den dominierenden Relationalen Datenbanken.
Die zwei Kernelemente dieser Bewegung sind aus typischen Anforderungen für moderne Webanwendungen erwachsen: Vereinfachung der Datenhaltung für die Entwicklung und  verbesserte horizontale Skalierbarkeit im Betrieb.

Zur Praxis

Die Installation von MongoDB selber geht recht fix. Dazu holt man sich dann noch die mongo-Eweiterung für PHP per pecl install mongo und fügt extension=mongo.so in der php.ini dazu.

Das reicht schon um loszulegen:

<?php
// automatische Verbindung mit localhost:27017
$mongo = new Mongo();
// $blog ist ein MongoDB-Objekt (vergleichbar mit MySQL-Datenbank, wird automatisch angelegt)
$blog = $mongo->blog;
// $posts ist eine MongoCollection (vergleichbar mit SQL-Tabelle, wird automatisch angelegt)
$posts = $blog->posts;
// schreiben
$posts->insert(array(
    'slug' => 'foo-bar',
    'title' => 'Foo Bar',
    'body' => '<p>Bar foo foo bar …</p>',
    'date' => new MongoDate(),
    'tags' => array( 'footag', 'bartag', 'foobar'),
));

Die Datenbank und Collection (Tabelle im SQL-Sinne) werden zur Laufzeit automatisch erstellt. Da auch die Anmeldung an der Datenbank ohne Authentifizierung auskommt, ist bequemer weise kein vorheriger administrativer Zugriff auf die MongoDB nötig.

Vorteile von dokumentorientierten Datenbanken

Das direkte Speichern nativer Arrays wie im Beispiel ist natürlich überaus praktisch. Strukturen wie man sie oft sowieso schon im eigenen Code verwendet können mit geringen Manipulationen direkt abgespeichert werden. Joins über IDs oder komplizierte Zwischentabellen um m:n Beziehungen darzustellen, wie aus der SQL-Welt, fallen im Idealfall komplett weg (wie oben bei den ‚tags‘).

Der schemalose Ansatz der dokumentenorientierten Datenbanken macht die Entwicklung flexibler denn das umständliche Anlegen neuer Felder oder Tabellen über Administrationswerkzeuge ist nicht mehr nötig. Das macht das Aufspielen neuer Versionen auf Live- oder andere Entwicklungsserver oft deutlich einfacher.

Zwei weitere oft genannte Argumente für NoSQL und somit auch MongoDB sind einfache horizontale Skalierbarkeit und Performancevorteile für viele Anwendungsfälle. Der Trumpf Skalierbarkeit lässt sich aber natürlich erst bei wirklich großen Projekten ausspielen.

Innere Umstellung aus SQL-Sicht

Allerdings muss man den eigenen Entwicklungsansatz auch auf diese neuen Datenmodelle einstellen. Denn z.B. die Performancegewinne bei MongoDB erreicht man zu einem Teil erst dadurch, dass man möglichst versucht ohne „Joins“ auszukommen. Das bedeutet dann in der Praxis das man alle Seitendaten für unseren Blog-Post z.B. in einen einzigen Datenbank-Eintrag schreibt:

<?php
// erweitern des obig angelegten Dokumentes
$posts->update(
    array( 'slug' => 'foo-bar'), // quasi eine where-Bedingung
    array( '$set' => array( // ohne set $set würde es den ganzen Post ersetzen
        'user' => array(
            'name' => 'Mr. Foo',
            'nick' => 'mrfoo',
        ),
        'comments' => array(
            0 => array(
                'date' => new MongoDate(),
                'name' => 'Ms Comment',
                'mail' => 'ms.comment@example.com',
                'text' => 'Bar foo bar …',
            ),
            1 => array(
                'date' => new MongoDate(),
                'name' => 'Mr Comment',
                'mail' => 'mr.comment@example.com',
                'text' => 'Foo bar foo …',
            ),
        ),
    ))
);
?>

Einiges davon wirkt natürlich nach vielen Jahren SQL-Erfahrung etwas unsauber. Erfahrungen zeigen aber das viele der Einsprüche für die Praxis nicht viel Bedeutung haben.
Der erste und vielleicht auch wichtigste Schritt im Umstieg zu NoSQL-Modellen ist es, den gewohnten Join-Ansatz aus den eigenen Gedanken so weit wie möglich zu verbannen.

Daten abfragen

Die Where-Bedingungen von Abfragen werden ebenfalls als Arrays übergeben. Einfache Abfragen sind so noch recht übersichtlich, aber bei komplexeren Statements geht dadurch manchmal die Orientierung verloren.

Um unser Beispiel abzuschließen, hier eine Abfrage plus vereinfachte Ausgabe:

<?php
$doc = $posts->findOne( array( 'slug' => 'foo-bar'));
echo '<h1>'.$doc['title'].'</h1>';
echo '<em>'.$doc['user']['name'].'/'.date('r', $doc['date']->sec).'</em>';
echo $doc['body'];
echo '<ul>';
foreach( $doc['comments'] as $key => $comment) {
    echo '<li>'.$comment['name'].': '.$comment['text'].'</li>';
}
echo '</ul>';
?>

Vorteile von MongoDB

Weitere Vorteile speziell von MongoDB sind die Indizes die auch auf tief liegende Felder (z.B. comments.date) gelegt werden können.
Ebenfalls hervorzuheben ist das auch große Binärdateien mit GridFS gleich mitverwaltet werden können.
Auch die Dokumentation (PHP) ist für ein jüngeres Projekt sehr gut!

MongoDB hat im Vergleich zu anderen NoSQL-Datenbanken noch eine recht hohe Ähnlichkeit zu SQL-Datenbanken. Das macht den Übergang einfacher.

Alternative: CouchDB

Allgemein ist das NoSQL-Biotop noch sehr unübersichtlich. Es gibt viele verschieden Ansätze (Dokument-, Zeilen- oder Key-Value-orientiert) mit jeweils vielen verschiedenen Produkten.
Ein ähnliches Produkt unter den bekannteren Namen ist CouchDB. Im direktem Vergleich MongoDB vs. CouchDB hat MongoDB Vorteile durch eine bessere echte PHP-API, In-Place-Updates und dem leichteren Umstieg. CouchDB punktet vor allem mit größerer Datensicherheit und unabhängigerer Entwicklercommunity.

Wann lohnt sich NoSQL?

Dokumentenorientierte Datenbank wie MongoDB und CouchDB haben Vorteile wenn viele verschiedene Datenfelder am Ende ein Dokument (z.B. Blog-Eintrag oder CMS-Seite) darstellen und man sich viel Flexibilität in der Entwicklung wünscht.
Weniger geeignet scheinen NoSQL-Systeme für Aufgaben aus dem Rechnungswesen die viele variierende Aggregationen aus Zahlenwerten benötigen.

Fazit

NoSQL ist natürlich auch ein Buzzword und SQL-Datenbanken werden selbstverständlich auch weiterhin gebraucht. Trotz alle dem bringt die NoSQL-Welle viele interessante neue Ansätze die sicherlich in einigen Bereichen in Zukunft zum Standard gehören werden.

PHP bietet oft neue Releases mit neuen Features. Nicht immer sind es große Features, aber ab und zu erblicken wir erfreut Funktionen, die das Programmieren vereinfachen bzw. vorher selbst geschriebene Funktionen überflüssig machen. Doch einige Features wünscht man sich schon lange, und es gibt sie einfach nicht. Welches genau diese gewünschten Features sind möchte ich hier sammeln, vielleicht liest es ja jemand aus dem PHP-Team mit und schlägt es für eine Umsetzung vor.

Da ich auch nach minutenlangem Überlegen nichts gefunden habe was mit an der Sprache fehlt, möchte ich hier die Überlegungen von Florian Heinze vorstellen.

—————————————————–

Eine kleine Funktion die das Vorhandensein einer Variablen oder eines Array-Elements prüft, und dann entweder die Variable zurückliefert oder NULL.

$var = isset($foo) ? $foo : null;

vereinfachen zu

$var = ifset($foo);

Die beiden folgenden Zeilen sind nicht equivalent und tun nicht das was gewünscht ist:

$var = $foo ?: null;
$var = isset($foo) ?: null;

—————————————————–

Nachträglich Getter+Setter für ein Klassen-Attribut erstellen, ohne die aufrufenden Befehle zu ändern. In C# funktioniert das so:

private string _name;

public string Name
{
    get { return this._name; }
    set { this._name = value.ToLowerCase(); }
}

—————————————————–

Die vorhandene Funktion array_merge_recursive fügt Arrays nicht so zusammen wie man es manchmal benötigt, beispielsweise für Konfigurationsdateien, wo man eine Hauptkonfiguration hat und dann je nach Umgebung eine weitere Konfiguration dazulädt, wobei die spezielleren Einstellungen die Standardwerte überschreiben sollen. Bei array_merge_recursive werden Arrays zwar zusammengeführt, aber die Werte im selben Array werden nicht überschrieben, sondern angehängt.

<?php
$ar1 = array("width" => 10, "color" => array("favorite" => "red"));
$ar2 = array("color" => array("favorite" => "green"));
$result = array_merge_recursive($ar1, $ar2);

wird zu

array(
    "width" => 10,
    "color" => array(
        "favorite" => array("red", "green")
    )
)

gewünscht ist aber in diesem Fall

array(
    "width" => 10,
    "color" => array(
        "favorite" => "green"
    )
)

—————————————————–

Die größte Heldentat um PHP sicherer zu machen wäre für htmlspecialchars() und htmlentities() kürzere Versionen anzubieten. Diese beiden so wichtigen Funktionen sind ja sowas von zu lang und hässlich in HTML-Views das sie keiner verwenden mag 😉 Besser wäre ein schlichtes kurzes esc()!

—————————————————–

Über was seid ihr so gestolpert in den letzten Jahren, was fehlt, was ist stark verbesserungswürdig, wofür müßt ihr andauernd Helferfunktionen bereitstellen, was eigentlich die Sprache bereits mitliefern sollte?