Datenbank Frameworks... Welche Vorteile bieten diese?

[Lemmy]

Zitat von TigerLilly:

Was (für mich) für ein ORM/DB Framework spricht:
- Datenbankunabhängigkeit - Dein ORM schiebt zwischen die DB und die Anwendung eine Schicht und dein Code funktioniert gegen mySQL und SQLite ohne Änderung.
- Du klebst beim Programmieren nicht mehr an Tabellen und Attributen, sondern arbeitest mit Klassen und musst dir über die Datenbank keine Gedanken machen
- Es gibt kein Herumgefrickle mit SQL Statements mehr
- Durch die Klassen erhälts du ein viel höheres maß an Testbarkeit und geringerer Abhängigkeiten
- Du entwickelst eine anderen Programmierstil, der nicht mehr an die Datenbank denkt.

Die Datenbankunabhängigkeit ist für mich (aktuell) kein Thema, der Rest kann aber nicht oft genug betont werden:
Wenn Du ein Stück Code schreibst, das ein Problem lösen soll, dann hast Du unterschiedliche Schichten:
* fachliche Logik (was soll überhaupt gemacht werden)
* Sprachlogik (wie funktionieren Schleifen, Bedingungen)
* GUI
* Datenbank (Abfrage, Speicher, Indizes...)

Mit einem ORM ist der dritte Punkt oben weggekapselt. Und wenn Du es dann noch schaffst, deine Logik testbar in Klassen zu verpacken, kannst Du die GUI aus dem aktuellen Problem streichen und das ganze ggf. auch am Ende mit Unittests absichern, d.h. Du musst nicht mehr selbst testen, sondern lässt testen.

Zitat von TigerLilly:

Das ORM löst aber nicht alle Probleme:
- zumindest bei Aurelius gibt es (noch) keine Bulk-Operationen
- destruktive DDLs (Felder löschen) sind nicht möglich

Gegenfrage: sind das Aufgaben des ORM? Wenn ja, und das ORM bietet keine solchen Möglichkeiten, warum das ORM nicht erweitern? Und wenn nein: Warum dann nicht Klassen schaffen, die genau das machen, aber eben die Komplexität der SQL wiederum vor dem Rest verbergen....?

Zitat von TigerLilly:

- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Den Punkt verstehe ich nicht wirklich. Warum soll ich SQL persistieren? Und wohin?

[jobo]

Anhand der Antworten wird schon deutlich, dass ein Framework, auch wenn es ein Datenbank Framework genannt wird, ganz unterschiedliche Funktionen realisieren kann.

Hier müsste man sich dann fragen, was man (davon) braucht.

Ohne es jetzt groß aufzuhängen, ich finde ein Blick in eine DB aus einem Persistenzsystem immer mal wieder gerne gruselig. Es liegt auf der Hand, dass die Abstraktion der DB Fähigkeiten erstmal bedeutet, dass der kleinste gemeinsame Nenner genutzt wird.
Was mich zu dem anderen Punkt bringt: Performance dürfte hier von Fall zu Fall schon eine (unangenehme) Rolle spielen. Meist sind aber die Projekte so klein, dass eine DB das alles einfach wegatmet und man ruhig schlampig mit ihr umgehen kann.

[Uwe Raabe]

Zitat von jobo:

Performance dürfte hier von Fall zu Fall schon eine (unangenehme) Rolle spielen. Meist sind aber die Projekte so klein, dass eine DB das alles einfach wegatmet und man ruhig schlampig mit ihr umgehen kann.

Ich erinnere mich da an ein Projekt, bei dem damals noch die erste Version von Aurelius zum Einsatz kam. Das funktionierte alles ganz wunderbar bis zu dem Zeitpunkt, wo die Datenbank vom lokalen Netz in Azure migriert wurde. Das Erzeugen einer (DB-)Objektliste hatte dann gleich alle Objekte aus der DB geladen, mitsamt aller Child-Objekte (Master-Detail) in der kompletten Hierarchie-Tiefe. Die ganzen Optimierungen, die das DAC in so einem Fall bereitstellt, waren damit hinfällig. Das Programm öffnete sich erst nach mehreren Minuten.

Aber das hat TMS dann ja später erfolgreich in den Griff bekommen. Leider konnte ich darauf damals nicht warten und musste es doch wieder auf die alte Tour machen.

[TigerLilly]

Zitat von Uwe Raabe:

Ich erinnere mich da an ein Projekt, bei dem damals noch die erste Version von Aurelius zum Einsatz kam. Das funktionierte alles ganz wunderbar bis zu dem Zeitpunkt, wo die Datenbank vom lokalen Netz in Azure migriert wurde. Das Erzeugen einer (DB-)Objektliste hatte dann gleich alle Objekte aus der DB geladen, mitsamt aller Child-Objekte (Master-Detail) in der kompletten Hierarchie-Tiefe. Die ganzen Optimierungen, die das DAC in so einem Fall bereitstellt, waren damit hinfällig. Das Programm öffnete sich erst nach mehreren Minuten.

Aber das hat TMS dann ja später erfolgreich in den Griff bekommen. Leider konnte ich darauf damals nicht warten und musste es doch wieder auf die alte Tour machen.

Ja, das stimmt - Stichwort LazyLoading.

[juergen]

Hallo,

danke an alle für die Hinweise!
Ich habe mir gerade mal ein Video von Aurelius angeschaut https://youtu.be/fIOntD73S8k
Das hat mir schon mal die Augen geöffnet. Sehr interessant.
Ich denke TigerLilly hat es gut beschrieben:

Zitat von TigerLilly:

Die Lernkurve ist allerdings auch beachtlich, für mich hat es eine Weile gedauert, das Konzept zu verinnerlichen. An Stelle dass du mit SQL herumtust, baust du halt ewiglange Delphizeilen zusammen. Aber hier hast du die Fehlerprüfung halt überwiegend schon zur Compiletime + nicht erst zur Laufzeit. Ich habe TQuerys echt verinnerlicht + das Konzept wegbekommen dauert. Aber je länger ich mit Aurelius arbeite und Dinge ausprobiere, desto eleganter wird alles.

Da ich DevExpress schon habe werde ich mich nun erst einmal näher mit dem ExpressEntityMapping Framework beschäftigen...

Allen einen guten Start in die neue Woche!

[Frickler]

Was ich mich immer gefragt habe - wenn es kein SQL mehr gibt, wie regelt man eigentlich statistische Asuwertungen und das Reporting, mal von ganz einfachen Listen abgesehen? Objektlisten laden und dann sozusagen von Hand aufsummieren, wie wir das ganz früher bei dBase gemacht haben? Also Auswertung auf dem Client statt auf dem Server?

[mkinzler]

Die eigentlich Speicherung erfolgt ja in einer Datenbank; und auf diese kann man natürlich auch SQL-Abfragen absetzen. Die ORM-Frameworks bieten aber wiederum auch an, Objektlisten wieder auf DataSets zu Mappen.

[jobo]

Zitat von Lemmy:

Zitat von TigerLilly:

- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Den Punkt verstehe ich nicht wirklich. Warum soll ich SQL persistieren? Und wohin?

Könnte mir vorstellen, dass es hier um die immanente Logik geht, die in einem SQL Statement steckt / stecken kann und die zwangsläufig (oder zum Glück) sehr kompakte Logik "Darstellungen" liefert.
In einem Objekt orientierten Programm zergliedern sich die Zusammenhänge in Klassenhierarchien (wovon man selten mehr als 2 Ebenen am Stück sieht) und komplexe Relationen gehen im Code unter. (Vielleicht sehe ich das als klassischer SQL Entwickler aber auch einseitig)

[TigerLilly]

Zitat von Lemmy:

Zitat von TigerLilly:

- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Den Punkt verstehe ich nicht wirklich. Warum soll ich SQL persistieren? Und wohin?

Naja, man kann zB für eine Suchmaske komplexe WHERE-Bedingungen vorformuliert in einer Tabelle ablegen und der User wählt dann aus, was er braucht. Oder du bereitest irgendwelche SQL-Statements als Abfragen vor. etc etc.