Best-Practices Datenbanken in Delphi

[TigerLilly]

"best practice" gibt es genug. Sie hängen von der Abstraktionsebene ab. TQuery, Datasnap, ORM, REST das sind unterschiedliche Abstraktionsebenen. Auf/Mit allen kann man gut arbeiten und Aufgaben lösen. Für alle gibt es "best practice".

Für neue Projekte setze ich ausschließlich Aurelius, ein ORM von TMS ein.

Unabhängig davon gibt es wohl grundsätzliche "best practice":
- UI und Logik trennen
- Unit-Tests
- SOLID

Aber das ist dann eine andere Sache.

[Frickler]

Direkte SQL Statement sind auf jeden Fall gefragt, wenns um Auswertungen (Reporting) geht. Niemand holt sich eine "Liste von TArtikel Objekten" und nudelt die durch, um eine nach Artikelgruppe gruppierte Summe von Preisen zu ermitteln...

[Lemmy]

Zitat von Frickler:

Direkte SQL Statement sind auf jeden Fall gefragt, wenns um Auswertungen (Reporting) geht. Niemand holt sich eine "Liste von TArtikel Objekten" und nudelt die durch, um eine nach Artikelgruppe gruppierte Summe von Preisen zu ermitteln...

das würde ich so inzwischen definitiv nicht mehr unterschreiben.

[himitsu]

Zitat:

das würde ich so inzwischen definitiv nicht mehr unterschreiben.

Aber doch wohl nur, wenn das Framework die Daten auch DB-seitig filtert (WHERE und ORDER BY selbst zusammenstellt)
und das nicht erst Client-seitig macht, nachdem es ALLE Daten/Objekte geladen hatte? (außer die sind/waren schon da)


Man kann sich natürlich auch Views erstellen (teilweise auch writeable), welche sowas filtern/gruppieren/sortieren, und dann darauf gehn.

[Lemmy]

Zitat von himitsu:

Zitat:

das würde ich so inzwischen definitiv nicht mehr unterschreiben.

Aber doch wohl nur, wenn das Framework die Daten auch DB-seitig filtert (WHERE und ORDER BY selbst zusammenstellt)

selbstverständlich holt man sich auch mit einem Framework nicht eine komplette Tabelle aus dem Datenspeicher (außer man braucht das komplett). Aber ich habe jetzt schon zu viel gesehen, als dass ich irgendwas grundsätzlich ausschließen würde.

Ich versuch seit gut 5 Jahren keine datensensitiven Komponenten mehr einzusetzen. Selbst dann wenn ich kein ORM zur Hand habe, schreibe ich halt für eine Tabelle 2 Methoden fürs laden und speichern. Die Zeit die ich im Anschluss bei Änderungen spare, weil ich Teile mit Unittests absichern kann steht in keinem Vergleich zu der Investition. Und auch die Reportausgabe ist mit den Objektlisten deutlich schneller, weil auch z.B. berechnete Felder deutlich einfacher umzusetzen sind.

das heißt aber nicht, dass ich, wenn es mal ganz schnell gehen muss, nicht doch ein DBGrid aufs Formular klatsche... Meist bereue ich spätestens dann das ganze, wenn die Quali mir das auseinander genommen hat

[jobo]

Na ist es nicht eher so, dass ich Daten, die aus einem Persistenzframework stammen, sowieso nur mit der Kneifzange per SQL abfragen und auswerten wollte? Ausnahme wäre vielleicht, wenn das Persistenzframework vereinfacht gesagt nur eine einzige Tabelle ausspuckt. Das kann man auch ohne weitere Intimkenntnis mit SQL durchnudeln.
Ein komplexes Objektmodel abgebildet auf eine relationale DB später unabhängig vom Framework per SQL zu verarbeiten, scheint mir ziemlich daneben. Außerdem breche ich damit das "Geschenk" der freien Klassendefinition im Programmcode.
Ich musste noch nie ein Persistenzframework per SQL durchackern, aber was ich teilweise an "Transformationen" sehe, steigert auch nicht die Lust darauf. Das geht bspw. schon mit dem Datum als String gespeichert los. (aber das ist ja eher eine Frage der Qualität des Framework)

[Mavarik]

hmm.. Delphi's Erfolg war sicherlich der RAD Ansatz. Klicke ein paar DBEdits auf die Form, ein bisschen Datenbank und "Verteiler"-Komponenten und fertig. Schon steht Dein Prototype. So wurden Versionen verkauft.

Keiner hat gesagt: "Das war nur ein Prototype, aber das echte Programm machen wir anders".

Was ist mit der guten "alten" Regeln? Nie Daten in visuellen Controls halten?
Besonders, da die Datenbank offen gehalten werden muss, damit die Daten angezeigt werden?
Was ist mit Daten laden in einem Background Thread?

Wer das nicht trotzdem schon mal gemacht hat, der werfen den das erste Byte.

Ich denke, Deine Datenbank-Strategie ist dann richtig, wenn alles läuft ohne ein einziges Form oder Datenmodul. Aber das ist nur mein Ansatz.

Mavarik

[TigerLilly]

Zitat von Frickler:

Direkte SQL Statement sind auf jeden Fall gefragt, wenns um Auswertungen (Reporting) geht. Niemand holt sich eine "Liste von TArtikel Objekten" und nudelt die durch, um eine nach Artikelgruppe gruppierte Summe von Preisen zu ermitteln...

Das stimmt so nicht. TMS Aurelius generiert die notwendigen SQL Statements + stellt die Daten uA in einem TDataset Abkömmling bereit. Das können einzelne Datensätze sein, aber auch beliebige Projektionen, Aggregierungen und Joins. Damit kannst du jedes Reporting Tool verwenden, das du möchtest.

Ein ORM, das die Daten zuerst in den Client runterzieht und dann erst bereitstellt, wär suboptimal. Wüsste jetzt auch keines, das das macht.