dedlfix: Rails Tabellen

Beitrag lesen

echo $begrüßung;

Doch so einfach sind die zu erledigenden Aufgaben nicht immer. Sobald man mehr als eine 1:1-Abbildung auf Datenbanktabellen haben möchte, fangen teilweise ziemliche Verrenkungen an.

Kannst du  bitte einen Verrenkung beschreiben?

Eine der Verrenkungen stand im nachfolgenden Satz: "eine Funktion in ein SQL-Statement einbinden"
Beispiel im Zend Framework: http://framework.zend.com/manual/en/zend.db.html#zend.db.adapter.write.insert - man muss diese Funktion oder einen Ausdruck in ein eigenes Objekt Zend_Db_Expr packen.

Auch andere datenbankspezifische Funktionalität lässt sich meist nicht nutzen, weil diese Frameworks oft (immer?) auf dem kleinsten gemeinsamen SQL-Nenner aufbauen, damit zum einen das Datenbanksystem austauschbar bleibt, und zum anderen nach oben hin eine einheitliche Schnittstelle zur Verfügung gestellt werden kann.

Weitere Beispiele:

  • Zusätzliche Statement-Attribute wie SELECT SQL_CALC_FOUND_ROWS (MySQL) und er nachfolgende Aufruf von SELECT FOUND_ROWS() oder INSERT ... ON DUPLICATE KEY UPDATE ...
  • Feld-Attribute: BINARY
  • Unterabfragen
  • Spezielle Feldtypen
  • Beziehungen über mehrere Datenbanken hinweg. (Z.B.: Jeder Kunde hat seine eigene Datenbank, doch das Verwaltungstool des Providers muss auf Verwaltungsdatenbank und Kundendatenbank gleichzeitig zugreifen.)

Die Railsmodelle mit ActiveRecords kennen eigentlich AFAIK 1:1, 1:n und m:n Beziehungen, die mit Attributen wie z.B. 'has_one' oder 'belongs_to' abgebildet werden.

Solche Beziehungen lassen sich oft auch mit den anderen Framworks abbilden. Doch das sind in meinen Augen auch nur mehr oder weniger 0815-Anwendungsfälle.

Ich meinte mit der "1:1-Abbildung" nicht die Beziehungen der Daten untereinander, sondern den Umgang der Frameworks mit den Tabellen. Jede Tabelle wird mit einer eigenen Klasse abgebildet. Natürlich kann man sie miteinander verknüpfen, aber nur für die vorgegebenen Standardfälle.

echo "$verabschiedung $name";