Best-Practices Datenbanken in Delphi

**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.

**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.

**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

**scrat1979**

Ich persönlich ziehe nicht-datensensitive Controls vor. In meinem Fall (netzwerkfähiger Terminplaner) lade ich mir die benötigten Daten in eine ObjectList. Dafür habe ich einen Server programmiert welcher die Anfrage des Clients entgegennimmt (Termin erstellen, löschen, Zeitspanne abrufen, etc.). Nur der Server kommuniziert mit der Datendank. Die Kommunikation zwischen Clients und Server geschieht ausschließlich mittels entsprechenden Objekten welche als Streams (verschlüsselt) über das Netzwerk geschickt werden. Die wenigen Berechnungen welche ich brauche mache ich dann tatsächlich in der ObjectList über entsprechende Methoden. Läuft stabil und vor allem schnell. Größere Auswertungen (Drucken bestimmter Termine etc.) mache ich am Server selbst (sehr selten benötigt) direkt über SQL.

Nur ein Beispiel: Das Anfragen und Empfangen von allen Terminen über 3 Monate (entspricht der Ansicht am Client) dauert ca. 2 Sekunden (ca. 3000 Termine). Termine erstellen, löschen etc. passiert ohne nennenswerte Verzögerung, wobei die Kommunikation mit der Datenbank mit Abstand die meiste Zeit „frisst“. Hier wären dann entsprechende Indizes zu setzen um die Zeit zu reduzieren.

**QuickAndDirty**

@OP
Für SQL Datenbanken sollte man immer TFDQuery benutzen.imho.
Für D-Base Artige Datenbanken(Dbase, Jet-Engine, &c. ) oder Memory-Tables ist die TfdTable komponente bestens geeignet.

[OT]
Irgendwie ist as aber schon schade, dass es keine Datenbank-Objekte gibt die keine Komponenten sind.
Ich fühle mich immer verunsichert wenn ich Datenbank-Befehle oder Queries in backgroundthreads laufen lasse.
Wenn ich Connection Objekt und Query objekt hätte wäre mir sicher auch viel wohler dabei...
Ich weiß auch nicht ob Create(nil) eine Komponente von den components und der Message loop im Hauptthread abtrennt.

[/OT]

**freejay**

Zitat von Relic:

Moin zusammen,

ich habe mich nun ein bisschen durch das Forum geklickt und diverse Datenbank Meinungen mir durchgelesen.
Dabei habe ich jetzt mehrfach gelesen, dass man von datensensitiven Komponenten (d.h. TDBEdit und ähnlichem) und auch den ganzen Table-Komponenten im Datenbankbereich Abstand nehmen sollte.
Gleichzeitig gab es aber auch Meinungen, dass die Methoden Post, Append und sowas meistens besser sind, als direkte SQL-Statements.

Ich habe die Entwicklung einer Legacy-Applikation (ohne Firedac oder ähnlichem) übernommen und habe nur vom vorherigen Programmierer gelernt. Daher würde ich mich freuen hier mal neue Ideen / Best-Practices zu erhalten.

In der von mir betreuten Applikation wird eigentlich so gut wie alles über die Tables, Ranges, Filter und datensensitiven Komponente gelöst und ich bin mir nun unsicher, was der richtige Weg ist.

Schöne Grüße!

Ich finde man ist bei datensensitiven Controls in der Auswahl der Komponenten und deren Möglichkeiten etwas eingeschränkt. Vor allem, was das Verhalten der Controls angeht. Ich arbeite daher immer mit "normalen" Controls. Das heißt aber noch lange nicht, dass man auf Gedeih und Verderb eine Legacy-Anwendung deswegen komplett umbauen muss. Vielleicht probiert man eine andere Lösung mal an einem neuen Modul aus oder bei einem, das sowieso umgebaut werden muss. Dann kann man mit beiden varianten Erfahrungen sammeln und am Ende herausbekommen, was im Anwendungsfall die bessere Lösung ist. Einen für alle Fälle "richtigen Weg" gibt es da meiner Meinung nach nicht.

**DasWolf**

Zitat von freejay:

Ich finde man ist bei datensensitiven Controls in der Auswahl der Komponenten und deren Möglichkeiten etwas eingeschränkt. Vor allem, was das Verhalten der Controls angeht. Ich arbeite daher immer mit "normalen" Controls.

Kannst Du das bitte mal genauer ausführen. Was sind für Dich normale Controls? Welche Möglichkeiten sind denn eingeschränkt?

**freejay**

Naja, "normale" Controls sind alle, die nicht datensensitiv sind (also nicht mit TDB... beginnen). Ich finde halt die Tatsache, dass die TDB... Komponenten sozusagen fest mit der Datenbank verdrahtet sind, limitieren. Natürlich kommt es total drauf an, was man gerade macht und vielleicht geht auch mehr als ich denke (mittlerweile?) mit TDB... Komponenten. K.A.

Aber ich zeige z.B. in einer Applikation die Daten von der Datenbank in einer verdichteten hierarchischen Form an (die Daten kommen dabei aus verschiedensten Tabellen) - siehe Anhang. Das ist mit einem datensensitiven Control (z.B. TDBGrid) einfach nicht möglich.