Hallo,

wie man an diversen Fragen von mir, die ich un letzter Zeit stellte, sehen kann bin ich z.Zt. auf der Suche nach einem passenden Tool zur Verwendung von Datenbanken in Ruby.

Ich habe dazu verschiedene Aufgaben mit verschiedenen Tools (activerecord, datamapper, sequel, sqlite, dbi, winole) gelöst. Einen Vergleich dazu habe ich jetzt veröffentlicht:
http://ruby.lickert.net/db_mapper/index.html
oder in Tabellenform: http://ruby.lickert.net/db_mapper/db_tab.html

Ich bin mir durchaus bewusst, das ich die Pakete nur unvollständig verstanden habe (insbeonders bei activerecord habe ich den Eindruck).

Insgesamt kam mir sequel bisher am meisten entgegen. Bei AR geht nach meinem Eindruck nichts ohne Models, bei Sequel konnte ich mit etwas SQL-Vorkenntnissen gleich loslegen. datamapper und sqlite kommen nicht in Frage (sqlite - also das ruby-gem, nicht die DB selbst- kann nur sqlite, bei datamapper fand ich noch keinen Weg zur Nutzung von ODBC.)

Ich schau mal, ob ich meinen Vergleich noch ausbaue (sortierung fehlt, Nutzen mehrerer DBs, ...). Und wenn ich sqlite (die DB) in ruby 1.9 zum laufen kriege, dann schaue ich da nochmal.

Generelle Frage an AR-Kenner: Brauche ich immer Models? Oder kann ich analog sequel auch etwas wie DB[:films] machen?

Um die Frage gleich aus der Definition zu beantworten: ActiveRecord ist ein ORM - ein Objekt-Relationaler-Mapper. Es setzt also Relationen aus der Datenbank automatisch in Objekte im Programm um - die im AR-Lingus nun mal Models heissen.

DataMapper zäumt das Pferd etwas anders auf, aber es gilt grundsätzlich das gleiche: DataMapper ist eine Objektpersistenzschicht, die auch SQL kann. DataMapper kann genauso problemlos in Couch oder Redis persistieren, wenn man das denn will, auch wenn gewisse Features (zum Beispiel Relationen) von diesen Stores nicht unterstützt werden. In DataMapper könnte man sogar sagen, dass es ohne DataMapper-Objekt garnicht geht, weil man sonst ja nix zum persistieren hat.

Wenn man dazu noch sieht, das DataMapper und ActiveRecord die Namen zweier bekannter Patterns sind, um eben solche Konstrukte zu implementieren, wird klar, dass es sich zentral um (volle) Objekte dreht.

Sequel dahingegen ist kein ORM, sondern eine Bibliothek zur Interaktion mit SQL-Datenbanken. Sequel::Model ist daher nur eine Erweiterung, der man durchaus auch anmerkt, dass sie nicht das Hauptaugenmerk der Sache ist. Unbequem ist sie zwar nicht, man muss sich aber viel selbst zusammmenbauen.

Gruß,
Skade

Hier möchte ich gleich mal eine Lanze für Rails 3 brechen. Dort gibt es dann Active Relation & Active Model.
Ein Model ist damit nicht mehr zwangsläufig an die Datenbank gebunden. Man hat all die netten Features
für ein Model, wie z.B. Validations, für Plain Old Ruby Object's. Weiterhin werden Statement's, wie find,
nicht gleicht gegen die Datenbank geschickt, sondern man wartet, bis
es notwendig ist (wie bei Datamapper). Damit kann man sich Stück für Stück kompliziertere Statements
erstmal aufbauen und dann ausführen lassen.

Man hat scheinbar ne Menge gelernt in Rails 3.

ActiveModel und ActiveRelation sind allerdings nur Interfaces, die vor den Mappern stehen und dafür sorgen, dass man Objekte bauen kann, die sich in Richtung Frontend alle gleich verhalten. Das erleichtert es Rails, generische Helper zu bauen.

Direkt in die Gruppe der ORMs passen sie nicht.

Gruß,
Skade

Zu der Sache mit Views in dem Artikel: man legt die über Migrationen an (auch DataMapper kann Migrationen) und verwendet sie dann von der Ruby-Seite aus, als seinen sie Tabellen.

DataMapper kann also automigrate, autoupdate und migrationen für komplexe Sachen im Stil von Rails.

Gruß,
Skade

Danke für diese nützliche Übersicht