PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Wer braucht noch PHP?

2. September 2008 um 07:43 · Gehört zu Ajax, Javascript, PHP (Allgemein)

Mir wurde die Existenz eines sehr interessaten Projektes nahegebracht. Denn wie entwickelt man mittlerweile eine Web-Applikation? Datenbank -> SQL -> PHP -> HTML -> Javascript und das Ganze auch am Besten dank AJAX etc. auch wieder in die andere Richtung. Kein Wunder, das man sich fragen muss, auf welchem Layer hat man denn eigentlich eine Funktionalität implementiert?

Warum sollte man sich also nicht ein wenig ausruhen auf der Couch.

couchDB ist eine Datenbank und noch im sehr frühen Entwicklungsstadium, aber fällt durch zwei Besonderheiten auf, die für Webentwickler geradezu einladend sind.

  1. Es gibt keine Tabellen im klassischen Sinne.
  2. Sie wird nicht durch SQL angesprochen.

Wie bitte? Was ist das bitte für eine Datenbank? Die Entwickler nennen ihr Konzept “Document zentric”. In der Datenbank werden also keine Tabellen oder ähnliches abgelegt, sondern alles in Flatfiles. Jeder Eintrag erhält einen Unique Identifier und alles andere kann man frei wählen, also die Struktur, den ein Eintrag hat. Ein neues Feld hinzufügen? Klar, einfach beim nächsten Mal mitspeichern. Text, Bilder, was auch immer? Egal, einfach einen Eintrag anlegen.

Und das soll effizient sein? Jetzt kommt der nächste coole Part. couchDB speichert alle seine Daten als JSON. Und jetzt kommt der Clou, es gibt kein SQL, sondern alle Operationen werden per REST-API ausgeführt. Neuen Eintrag anlegen, einfach ein PUT gegen die Datenbank, Daten abrufen? Machen wir doch ein GET. Aber etwas ähnliches wie ein SELECT muss doch auch gehen? Klar, man schickt eine Funktion gegen die jeder Eintrag geprüft wird, quasi (vereinfacht)

if ( type == ‘news’) return

anstatt

“SELECT * FROM `news`

da ist nicht viel verloren.

Und jetzt werde ich mal ausprobieren, ob man ein Web-App bauen kann, die nur aus Javascript (extJs) und dieser Datenbank besteht…

Ähnliche Artikel:

  1. Wer auf der Welt braucht temporäre Funktionen?
  2. Ext 2.0 mit PHP Backend

Daniel meint dazu:

2. September 2008 um 08:50

Und was machst du wenn dein User Javascript deaktiviert hat ;)

Ich geh mal davon aus das diese CouchDB weit langsamer sein wird als die alt bewährte SQL Struktur. Werds auch mal testen, hälts du uns auf dem Laufenden? ;)

Gruß
Daniel

Florian meint dazu:

2. September 2008 um 09:23

“Unlike SQL databases which are designed to store and report on highly structured, interrelated data, CouchDB is designed to store and report on large amounts of semi-structured, document oriented data. CouchDB greatly simplifies the development of document oriented applications, which make up the bulk of collaborative web applications.” - http://incubator.apache.org/couchdb/docs/intro.html

außerdem gibt es ja auch für js-libraries php-wrapper. also beim entwickeln fällt wohl eher javascript aus, da man meistens etwas mehr als datenbanken benötigt. und außerdem haben sich relationale datenbanken ja nicht umsonst durchgesetzt ;)

Stefan meint dazu:

2. September 2008 um 09:33

Uff, bei diesem Vorhaben sträuben sich mir ja die Haare zu Berge. Ich verfechte immer noch die These, dass man JavaScript nur als Add-On und niemals verpflichtend verwenden sollte.

Trotzdem bin ich natürlich auch auf das Ergebnis gespannt, wobei ich die gleichen Bedenken wie Daniel ob der Geschwindigkeit habe. Flat-Files werden mit steigender Größe einfach extrem langsam. Wobei ich keine Ahnung habe, wie man da mit präkompilierten Sprachen wie C, C++ etc. gegenwirken kann.

Die Trennung von Aufgaben geht übrigens z.T. noch weiter, wenn man z.B. XML + XSLT verwendet.
Ich kann mir übrigens nicht vorstellen, dass man nur mit JS und CouchDB eine sinnvolle Webapplikation realisieren kann. Wie willst du sonst die Daten sicher überprüfen, ohne dass ein Angreifer die Möglichkeit hat, den Code zu verändern. Das eignet sich allerhöchstens für interne Projekte.

Die Frage nach der Implementierung der Funktionalitäten legt sich meines Erachtens mit dem MVC-Pattern relativ schnell wieder. Model (Daten abfragen), View (Daten anzeigen) und Controller (Daten verarbeiten) sind klar abgetrennt und für clientseitige Zusätze kommt JavaScript (+AJAX) ins Spiel. In diesem Muster wäre CouchDB wieder das Model, aber vielleicht denke ich einfach zu engstirnig für solch eine ganz neue Idee. :)

timi meint dazu:

2. September 2008 um 11:12

Naja, Phil spricht hier direkt JS-Apps an - und das ist auch genau der Ansatzpunkt von CouchDB. Wenn JS deaktiviert ist, funktioniert dann weder die Applikation, noch die Datenbank-Verbindung. Die man dann ohnehin nicht benötigt.

Ich bin der Meinung, man sollte Javascript durchaus eine Chance geben. Wie man schon an Actionscript 3 sieht, sind ECMA basierte Programmiersprachen durchaus leistungsfähig und können erstklassik objektorientiert ausgebaut werden.

Ich sehe es eher aus Sicherheitsgründen kritisch. Denn JS-Apps sind letzen Endes immer quelltextoffen. Egal, wieviel Quelltext durch Komprimierer und Co. verschleiert oder aus externen Quellen teilweise nachgeladen werden. Irgendwie muss die DB-Verbindung ja autorisiert werden. Sei es durch eine Passphrase oder Session…

butzi meint dazu:

2. September 2008 um 16:29

Genau da sehe ich auch das größte Problem. Wenn die Daten per Javascript abgerufen werden, dann muss die Datenbank zwingend von extern erreichbar sein. Somit ist es jedem Menschen/Computer möglich eine Anfrage an die Datenbank zu stellen.
Man kann es nur schützen, wenn man PHP oder eine andere Sprache als Schleuse benutzt. Wobei man wieder PHP braucht … :)

Die Performance gerade bei Sortiervorgängen (neuestes Dokumen zuerst, um es einfach zu machen) wäre sehr interessant.

phil meint dazu:

2. September 2008 um 17:55

Das man damit im Augenblick keine produktiv Systeme bauen sollte, das ist mir auch klar und über Sicherheit muss in dem Fall sicher auch diskutiert werden.

Aber was ist denn mySQL, Oracle etc auch letztendlich irgendwann? Ein Flatfile, oder glaubt ihr, dass die Daten per Magie gespeichert werden. Und wer von euch hat schon mal Prepare, Views, Transactions und Trigger in einer Webapplikation benutzt? Ein verschwindend geringer Anteil würde ich vermuten. Alles Overhead für eine traditionelle Datenbank.

Warum baut mySQL denn eine neue Engine? Drizzle. Weil die traditionellen Datenbanken nicht für Webapps entwickelt wurden. Den SQL stößt in vielen Bereichen gerade an seine Grenzen, nicht nur im Web… Seid offen für neue Ansätze Leute, aber trotzdem gut über die Risiken nachdenken…

butzi meint dazu:

3. September 2008 um 09:41

Offen ist, meiner Meinung nach, jeder Entwickler. Allerdings müssen auch offensichtliche Argumente her, die eine Verbesserung durch eine neue Technologie bringen wird. Im Moment sind kaum Vergleichswerte da und das Konzept generell hört sich gut an, hat sicherlich aber auch sein Grenzen.

Das MySQL, Oracle und Co. auch nur mit Dateien hantiert ist ja nix neues. Allerdings lagern Sie ähnliche Daten in einer Tabelle/Datei, nicht jedes Dokument einzeln. Dadurch sind sie im Speicher besser in der Lage die entsprechenden Aktionen durchzuführen.
Bei dem Konzept von CouchDB kann jedes Dokument andere Eigenschaften haben. Eine Sortierung oder Auswahl von Elementen könnte somit schwierig werden, bzw. zu unerwarteten Ergebnissen führen.

Bin aber auch gespannt, wie sich die DB entwickelt. Vielleicht werden meine Bedenken ja noch entkräftet. :-)

phil meint dazu:

7. September 2008 um 09:21

Warum suchen dann gerade alle nach neuen Möglichkeiten, um Daten effizient abzurufen. Das Problem mit allen traditionellen SQL und zeilenbasierten Datenbanken ist, dass diese “Schreiboptimiert” sind. Aber in den heutigen Zeiten mit Internet etc, braucht es viel mehr Leseoptimierung. Google benutzt übrigens aus diesem Grund ihre eigene Datenbanktechnik, Facebook, etc. Alle machen was eigenes, weil die Systeme weder für die große Verteilung, noch für viele Lesezugriffe super sind.

couchDB ist übrigens super. Habe mittlerweile die erste kleine App, die sowohl Daten lesen, schreiben und updaten kann. Alles komplett in Ext und damit JS only…

Sortierung, Auswahl etc. ist super easy. Man definiert entweder einen materialisierten View über Dokumente, die oft abgerufen werden (alle Produkte) oder man kann adhoc Anfragen schicken. Eine Anfrage besteht aus einer JS Funktion, in der man definieren kann, wan ein Artikel ausgegen wird und man kann auch einen Schlüssel zur Sortierung definieren. Ein Konzept, was ich noch nicht ganz down habe ist, dass die Schlüssel selber auch wieder Arrays oder Objekte sein können und man damit bsp sortiert alle Blog-Artikel und direkt im Anschluss alle Kommentare ausgeben lassen könnte, weil der Schlüssel aus [BlogId, null] für den Eintrag und dann [BlogId, parseDate(comment.date)] besteht…

Habe ich aber nur gelesen und noch nicht probiert…

Update soon

Stefan meint dazu:

18. September 2008 um 15:18

Warum soll man sich auf die Couch legen, wenn man wie ein Jackrabbit rennen kann (http://jackrabbit.apache.org/)?

Oder ernsthaft: Mir scheint, dass Couch ein halber Schritt ist. Wenn man Jackrabbit und darüber noch Sling einsetzt (http://incubator.apache.org/sling/site/index.html), dann hat man genau das Verhalten, das Couch verspricht - und zusätzlich noch einige Gimmicks mehr.
PHP kann man dann auch nach wie vor Serverseitig verwenden, und so viel Javascript einsetzen wie man will - von kompletten AJAX Applikationen bis hin zu reinem HTML.

Hier gibt’s übrigens einen netten Screencast über Entwicklung via Sling: http://dev.day.com/microsling/content/blogs/main/firststeps2.html

phil meint dazu:

18. September 2008 um 18:03

Hmmh, das liest sich ja schon interessant, aber vielleicht ist ein halber Schritt ja genau das was man machen muss, damit man nicht über die Klippe fällt. Ich will ja gerade nicht auf 27 Layern meine Programme konsistent halten und PHP gerade nicht benutzen und trotzdem eine Applikation bauen können.

Ich kann ja auch, wenn ich will mit PHP oder Java oder was auch immer REST spricht die couchDB ansprechen, aber das Ziel war ja gerade andersherum, dass ich es schaffe eine DB anzusprechen OHNE noch eine weitere Sprache benutzen zu müssen und genau danach sieht es mir bei Jackrabbit und Sling wieder aus, dass ich dann die Servlets erst noch programmieren müsste, bzw. sonst fehlen die einfachen Beispiele, wie man es “out-of-the-box” benutzt…

Aber ich weiß, dass ich da in der Richtung anders ticke, als die meisten da draussen…

Stefan meint dazu:

19. September 2008 um 09:44

Das verstehe ich nicht ganz. Wenn du eine Applikation entwickeln willst, wirst du immer etwas Logik implementieren müssen, das nimmt dir auch die CouchDB nicht ab, oder?
Mit Sling kannst du auf 27 Layern entwickeln, aber keiner zwingt dich. In aller Regel reicht es, wenn du z.B. mit php oder jsps HTML Seiten renderst. Wer’s fancy will, kann auch mittels AJAX Ressourcen nachladen - ein GET Request liefert dafür automatisch JSON Objekte zurück. Dabei musst du dich auch überhaupt nicht um die Speicherung der Daten kümmern, ein POST-Request wird ganz automatisch entgegengenommen und eine entsprechende Knotenstruktur angelegt.

phil meint dazu:

19. September 2008 um 19:41

Also noch mal…

Wenn ich im Augenblick eine Applikation entwickele, dann muss ich eine Datenbank installieren, Schema anlegen, Foreign-Keys, Indexe etc. auf der Datenbank pflegen. Dann habe ich die Logik, die dann in PHP, Java oder was auch immer implementiert wird und die Logik ausführt. Auf der nächsten Ebene habe ich dann den User-Interface-Kram, der auch in PHP programmiert ist und mir HTML ausgibt. In dem HTML habe ich dann Javascript eingebunden, der meine Seite dynamisch macht.

Also ich habe folgende Ebenen:
DB->PHP->PHP->HTML->JS
die alle konsitent gehalten werden wollen und zwar abstrahiert sind, aber doch irgendwie voneinander abhängen.

Das Ziel mit couchDB und EXT war es auf genau zwei Ebenen zu kommen…
DB->JS
und genau das ist mir eben gelungen, durch die Architektur von couchDB mit dem REST Interface und EXT, in dem die gesamte Applikationslogik umgesetzt wird… Keine weiteren Ebenen dazwischen, nur ein HTML-Template in dem das initiale Layout per EXT definiert ist…

Und die aktuellen Architekturen zwingen mich eben zwar nicht in 27 Ebenen, aber mindestens in 5 zu programmieren…

Bernd meint dazu:

25. September 2008 um 11:48

Na ja - für mich der eigentlich immer etwas “Angst” vor Javascript hat wirds wohl ber der beschriebenen althergebrachten Art bleiben.
Aber natürlich schau ich mir das Projekt mal an - manchmal findet man ja überraschendes und arbeitserleichterndes.

Flüge meint dazu:

26. September 2008 um 17:05

Hmmm, so lange google kein JS versteht brauchen alle websites, die im Internet auch gefunden werden möchten PHP. Klare Sache. Deine Kritik kann ich vollkommen nachvollziehen, allerdings werden wir uns wohl noch etwas länger mit PHP beschäftigen, egal ob es uns lieb ist oder nicht.

phil meint dazu:

26. September 2008 um 17:26

Selbst auf die Gefahr hin mich zu wiederholen. Aber das ganze Experiment ist ja auch nicht für produktiv Webapplikationen gedacht. Aber überlegt euch mal, dass ihr eine Mini-DB für interne Zwecke hacken müsstet, wo früher vielleicht jemand im Unternehmen Access oder sowas benutzt hat. Das ganze dauert dann nur noch 5 Minuten, funktioniert und hat ein schickes AJAX Webinterface…

Michael meint dazu:

1. Oktober 2008 um 16:39

Also wir verlagern zunehmens die Anwendungen auf den Client. Gerade bei “internen” Anwendungen wie Systemen zur Datenpflege wo man Browser und BS eingrenzen kann, ist das unproblematisch. Schwierig wird es immer, wenn viele Browser bedient werden müssen. Javascript ist leider nicht immer JavaScript.
Das ist bei PHP zwar auch so - aber auf den Server eingrenzbar.
Ich finde die Idee sehr spannend, einen großteil der Arbeit auf den Client zu verlagern. Das macht die Anwendungen viel schneller und geschmeidiger.
Leider funktioniert das nur mit geringen Daten-bzw. Teilmengen. Webshops mit Millarden Datensätzen, wo es dann richtig nützlich werden würde, sind so nicht Administrierbar.

Kleine Projekte (z.B. kleinere Produktdatenbanken) , die wir früher mit Access gelößt haben, halte ich für durchaus umsetzbar.

Das große Problem an der Datenausgabe sind die Suchmaschinen, die Abfragen in JavaScript nicht durchführen und somit aus der Geschichte raus sind.

Ich bin gespannt, wann sich auch das Problem erledigt hat…

Rob meint dazu:

8. Oktober 2008 um 16:47

Interessante Geschichte, werde ich mir auch mal bei Gelegenheit anschauen. An die JS-Kritiker der dezente Hinweis, daß man mehr und mehr Probleme hat, das Internet zu nutzen, wenn JS deaktiviert ist. Sicher, für Internetseiten die lediglich der Anzeige von Inhalten dienen ist JS vielleicht überflüssig, aber bei Webapplikationen kommt man heutzutage kaum noch darum herum. Der Vorteil von AJAX und CouchDB liegt auf der Hand: Die Daten werden in dem Format abgelegt, in dem sie dann auch an den Client übertragen und interpretiert werden. Decode und encode fallen somit weg und soweit ich weiß haben die führenden Browserhersteller schon eine sichere Alternative zu Eval() angekündigt.
Für SEO muss man derzeit noch viel tricksen, wenn man mit AJAX arbeitet, aber auch das ist nur noch eine Frage der Zeit, denke ich.

Stefan2 meint dazu:

13. Dezember 2008 um 10:16

In den Kommentaren wird ja munter durcheinander geworfen.

Javascript muss nicht im Frontend eingesetzt werden (kann aber und ist sicher eine flotte einfache Variante).
Die CouchDB wird über REST-API angesprochen. Das geht einfach über AJAX/Javascript-Calls, kann aber genauso server-seitig über PHP, Java, Ruby, … angesprochen werden.
Das Ganze hat also mit Javascript im Browser, Suchmaschinen-Abfragen, etc. nicht viel zu tun.
Relationale Datenbank mit CouchDB zu vergleichen ist Unsinn. CouchDB ist Dokumenten-basiert. Dementsprechend muss auch in den Köpfen die Abfrage-Methodik umgestellt werden bzw. muss natürlich überprüft werden inwiefern die Anwendung eher “Dokumenten”-basiert ist. Extrem relationale Strukturen machen auf Basis CouchDB eher keinen Sinn.
Für den produktiven Einsatz ist die CouchDB in vielen Aspekten sicher noch zu neu (s. auch die Website von CouchDB bzgl. der Sicherheit/Berechtigungskonzepten/etc).
Klasse finde ich die Möglichkeit Views über server- bzw. datenbank-seitiges Javascript zu definieren.
Insgesamt ein höchst interessantes, spannendes Projekt, wo es sich sicherlich lohnt die Weiterentwicklung im Auge zu behalten.

Jan meint dazu:

17. Dezember 2008 um 02:41

Datenbank-Sätze von vornherein als Jsons zu behandeln finde ich durchaus spannend und zukunftsträchtig. Wer bereits in JavaScript mit Json-Daten hin und her jongliert hat, wird das vielleicht verstehen. Aus für kompliziertere Web-Anwendungen die ich programmiert habe, hätte Couch denke ich Sinn gemacht - unter anderem ein Lern Tool für Vokabeln oder bei einem Chat. Für letzteres habe ich müssig einen Ajax-Request an PHP verschickt, dort die entsprechende Funktion aufgerufen, SQL-Query, den Result auf JSON umgewandelt, die Daten dann per Ajax zurückgeschickt und im JavaScript wieder extrahiert… Mit CouchDB hätte ich mir diese ewige Ajax-Spalterei theoretisch sparen können.
Zudem kommt hier die möglichkeit Daten “mehrdimensional” zu speichern dazu! Denn eine Datenbank-Tabelle ist im Grunde doch nichts anderes als ein Zwei-Dimensionales Feld?

JSON und PHP, aber bitte JavaScript like! | Hooda Blog meint dazu:

20. Dezember 2008 um 05:57

[...] (Prototype, und besonders Mootools). Angeregt durch einen Interessanten Artikel über couchDB auf PHP Blogger, eine Datenbank, welche angeforderte Datensätze eben im JSON-Format zurückgibt (und das geht als [...]

netz-informant.de meint dazu:

20. Januar 2011 um 16:26

Also ruft der User die ganzen Aufrufe auf ! Was ist, wenn die Seite das erste mal aufgebaut wird. Er müßte in diesem Fall eine Seite mit lautet div’s haben die leer sind und nun werden die Inhalte aus der DB geholt. Leuchtet mir nicht ein. Ich baue sonst meine Seite auf dem Server auf. Hole mir alles aus der DB und schicke die Seite dann ab. Nachladen kann ich dann auch per Ajax. Weiterhin finde ich das Konzept etwas chaotisch. Man nehme mal eine echt große Datenbank mit vielen Daten. Nun darf jeder speichern was er will und wie er will. Keine Struktur und alles durcheinander.

phil meint dazu:

20. Januar 2011 um 18:37

Hi Netz-Informat,

nach so langer Zeit dann mal wieder Aktivität hier im Post?! Ok. Viel hat sich zu damals nicht geändert. EXTJS (oder mittlerweile ja Sencha) ist im Prinzip in der Lage aus noch nicht mal div’s, dafür aber Javascript Code dir sehr schöne User-Interface Oberflächen zu erstellen und die einzelnen Komponenten rufen dann direkt ihre Daten ab.

Außerdem ist es bei couchDB auch nicht so, dass jeder alles speichern kann wie er will. Das muss quasi schon programmiert sein und das Konzeot von No-SQL ist ja auch für besondere Anforderungen ausgelegt und nicht als Ersatz für “normale” Relationale Datenbanken.

Aber nimm mal den Facebook-Newsfeed als Beispiel. Wenn du normal relationell denkst, dann brauchst du für die verschiedenen Dinge jeweils eigene Tables, also für Status-Updates, Links, Video etc. Mit einem Konzept wie couchDB kannst du das alles in eine “einzige” Tabelle packen, was dir dann sehr vieles vereinfacht in der Ausgabe und auch in Rechenzeit, wie z.B. für Abfragen an die einzelnen Tabellen.

Vielleicht hilft das das Konzept etwas besser zu verstehen. Viele Grüße

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung