Ist CouchDB am besten für dynamische Sprachen geeignet?

Question

Ich bin vertraut mit CouchDB und die Idee des Abbildens ihre Ergebnisse Scala-Objekten sowie finden einige natürliche Weise iteract mit ihm, kam sofort.

Aber ich sehe, dass dynamische Sprachen wie Ruby und Javascript Dinge tun sehr gut mit dem json / dokumentenzentrierten / shchema frei aproach von CouchDB.

Jeder gute aproach Dinge mit Couch in statischen Sprachen zu tun?

Answer 1

Ich verstehe, dass CouchDB rein mit JSON-Objekten funktioniert. Da JSON nicht typisiert ist, ist es verlockend, zu glauben, dass es natürlich für dynamische Sprachen geeignet ist. Allerdings XML ist in der Regel nicht typisiert auch, und Scala hat eine sehr gute Bibliothek Unterstützung für das Erstellen und Bearbeiten von XML. Für eine Erforschung der Scala XML-Funktionen finden Sie unter: http://www.ibm.com/ developer / library / x-scalaxml /

Ebenso mit JSON. Mit der richtigen Bibliothek Unterstützung kann mit JSON Umgang fühlt sich natürlich auch in statischen Sprachen. siehe für einen Ansatz mit JSON-Daten in Scala zu tun hat, diesen Artikel: http://technically.us/code/x/weaving-tweed-with-scala-and-json/

Mit Objektdatenbanken im Allgemeinen, manchmal ist es zweckmäßig, ein „Modell“ (unter Verwendung von zum Beispiel einer Klasse in der Sprache) zu definieren und verwendet JSON oder XML oder ein anderes nicht typisiert Sprache eine serialisierte Darstellung der Klasse zu sein. Die richtige Bibliothek Unterstützung kann dann zwischen der serialisierten Form (wie JSON) und den In-Memory-Datenstrukturen, mit statischer Typisierung und all den Leckereien übersetzen, die mit ihm gekommen. Für ein Beispiel für diesen Ansatz findet Fahrstuhl-Rekord, die Konvertierungen in und aus JSON hinzugefügt: http: //groups.google.com/group/liftweb/msg/63bb390a820d11ba

Answer 2

Ich frage mich, ob Sie die richtige Frage gestellt. Warum verwenden Sie Scala, und nicht die dynamischen Sprachen? Wahrscheinlich wegen einer Güte, die Scala bietet Ihnen das ist wichtig für Sie, und ich nehme an, Ihre Code-Qualität. Warum dann nicht verwenden Sie einen „statisch typisiert“ (d-Schema-basierte) Datenbank entweder? Wieder einmal gehe davon aus ich gerade, aber die Fähigkeit zu reagieren kommt in den Sinn zu ändern. Die Produktion von SQL-Datenbanken haben eine schreckliche Tendenz sehr schwer zu ändern und Refactoring.

So, Ihre Daten ist schwach typisierten und Ihre Code ist stark typisiert. Aber irgendwo werden Sie den Übergang machen müssen. Dies bedeutet, dass irgendwo, haben Sie ein „Schema“ für Ihre Daten, auch wenn die Datenbank keine hat. Dieses Schema wird von den Klassen definiert Sie Mapping Couch Dokumente auf. Dies macht durchaus Sinn; die meisten Anwendungen von Couch, die ich gesehen habe, haben einen Schlüssel wie „Typ“ und für jeden Typ mindestens einem gemeinsamen Satz von Schlüsseln. Ob Hand-Karte der JSON zu diesen Scala Klassen oder zu verwenden, z.B. Phantasie Reflexion Werkzeuge (langsamer, aber ziemlich) oder einige sogar ausgefallenere Scala Feature, dass ich noch neu bin auf ein Detail. Beginnen Sie mit der easy-but-langsam ein, dann sehen, ob es schnell genug ist.

Die große Sache tritt auf, wenn Ihre Klassen, das heißt Ihr Schema, Veränderung . Statt Ihre Tabellen von ALTER'ing, können Sie einfach die Klasse ändern, stellen Sie sicher, dass Sie etwas klug tun, wenn aus irgendeinem Dokument ein Schlüssel, den Sie erwarten, fehlt (weil es auf einer älteren Version der Klasse beruhte), und schon kann es losgehen. Als Reaktion auf Änderung ist noch nie einfacher, und noch ist der Code als statisch typisiert wie es bekommen kann.

Wenn das nicht gut genug für Sie ist, und Sie wollen kein Schema überhaupt, dann sind Sie effektiv sagen, dass Sie nicht wollen, Klassen verwenden zu definieren und Ihre Daten zu manipulieren. Das ist auch in Ordnung (obwohl ich keinen Gebrauch vorstellen kann), aber dann ist die Frage nicht über dynamische vs statischen Sprachen, sondern darüber, ob überhaupt klassenbasierten OO-Sprachen zu verwenden.