Best-Practices Datenbanken in Delphi

[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!

[stahli]

Datensensitive Komponenten wie TTable sind sehr einfach zu benutzen. Zum Lernen ist das nicht verkehrt.
Aber wenn es um größere Projekte geht und/oder die Anwendung Daten über ein Netzwerk oder gar Internet leiten muss, ist das der falsche Ansatz.

Dann sollte man die Datenzugriffe optimieren oder ein entsprechendes Framework nutzen (in Delphi je nach Version nicht ganz so einfach).
Die Lese- und vor allem Schreibzugriffe sind dann natürlich komplexer.

[Relic]

@Stahli:

Danke für deine schnelle Antwort! Mit Frameworks meinst du sowas wie FireDAC?! Da gibt es ja auch Tabellen etc.?

[stahli]

FireDAC würde ich eher als Datenbanktreiber ansehen.
Als Framework würde ich eher so etwas wie ORM´s sehen, hatte aber nichts ganz spezielles im Auge.

Ich will mich zu dem Thema mal nicht weiter profilieren, bin da nicht wirklich kompetent.
Aber Du wirst hier noch gute Tipps bekommen... :-)

[haentschman]

Moin...8-)

Zitat:

und ich bin mir nun unsicher, was der richtige Weg ist.

Das entscheidet eigentlich jeder für sich. :P Du kannst eigentlich nur die verschiedenen Varianten anschauen und entsprechend deiner Aufgabe entscheiden. :wink:
Die Aufgabe des Programmes ist entscheidend:
1. lokal installiert (1 Benutzer)?
2. lokal mit mehreren Benutzern?
3. Server mit mehreren Benutzern?
4. Datenbank grundsätzlich Datenbank mehrbenutzerfähig? (Desktopdatenbank, SQL Datenbank etc.)
5. separater Computer (Server) für die Datenbank?
..usw.

Meine Meinung:
Ich verwende in meinen Anwendungen ein eigenes mini ORM. Die Datenbankzugriffe sind über Interfaces von der Anwendung entkoppelt. Nur das Interface kennt den Ort, und die Zugriffskomponenten, wo die Daten herkommen. Die restliche Anwendung arbeitet intern mit Objekten. Die Anwendung sagt dem Interface "hole alle Kunden". Das Interface gibt dann der Anwendung z.B. eine Liste mit den Objekten (TKunde) zurück. Der Anwendung ist dann egal wo die Daten herkommen. Datenbank, Rest...:thumb:

Was ich meine: Diese Variante ist für ein ein Testprogramm zu viel. Da tut´s auch ein datensensensitives Edit. :zwinker:

Zitat:

so gut wie alles über die Tables, Ranges, Filter und datensensitiven Komponente gelöst

Tables sind eher schlecht. Das funktioniert eigentlich nur mit kleinen Datenmengen. Die Table holt sich immer alle Daten! Erst clientseitig wird die "Anzeige" gefiltert. Trotzdem ist alles da. Ich hole mir per SQL nur die Daten aus der Datenbank die ich benötige.

Zitat:

Aber wenn es um größere Projekte geht und/oder die Anwendung Daten über ein Netzwerk oder gar Internet leiten muss, ist das der falsche Ansatz.

+1 :thumb:

:wink:

[Jasocul]

Es gibt mMn kein pauschales Best-Practice.
Beispiel:
Ich habe TTable nur ganz am Anfang mal ausprobiert und festgestellt, dass es für mich unbrauchbar ist. Aber kürzlich hatte ich eine kleine Anwendung, für die ich es dann doch verwendet habe, weil es die effizienteste Lösung war. Ich brauchte auf jeden Fall alle Datensätze (bis zu 400.000). Eine Visiualsierung war nicht erforderlich. In dem Fall eine einfache und praktikable Nutzung von TTable, um eine schnelle Lösung zu haben.

Fast alle Anwendungen, die ich programmiere, sind Inhouse-Anwendung (DB-Server im externen RZ mit GBit-Leitung). Das meiste ist dabei Read-Only. Die meisten der existierenden Anwendungen wurden vor meiner Zeit in der Firma entwickelt. Zu der Zeit gab es kein Live-Binding, wie es heute verfügbar ist. Also wurden oft datenbanksensitive Komponenten eingesetzt. Vieles wurde in Grids dargestellt. Der Komfort eines TDBGrids (oder bessere Third-Party-Komponenten), ist nicht zu unterschätzen. Wenn die Liste einfache Infos aus einen Master-Tabelle benötigt, sind das idR auch DB-Komponenten. Sobald aber mit den Daten "gerechnet" wird, gibt es ein Interface und DB-Komponenten haben sich erledigt.

Sobald es um Anwendungen geht, die nicht Read-Only sind, sieht die Situation anders aus. Direkte Erfassung in DB-Komponenten sind dann die Ausnahme. Ganz besonders, wenn Plausibilitätsprüfungen erforderlich sind, was bei uns die Regel ist. Da ist ein Interface dann deutlich einfacher, als mit DB-Komponenten.

Zum Thema Filter:
Ist bei mir ein NoGo. Da ich fast ausschließlich TQuery verwende, kann ich die Filter auch gleich in die SQL-Abfrage einbauen. Wenn ich alte Projekte von meinen Vorgängern öffne, bin ich jedesmal am Fluchen, wenn ich wieder über Filter stolpere. Warum soll ich erst Daten von der DB holen, wenn ich die dann wieder einschränke? Dann kann ich auch gleich einschränken.

[jobo]

Man muss datensensitive Komponenten und TTable Komponenten wohl getrennt betrachten. Die TTable Komponenten stammen ja aus der DBISAM Zeit und diese Zeit ist wohl irgendwie vorbei. Ausnahmen wurden schon genannt.

Ich habe viel mit datensensitiven Komponenten gearbeitet, unter Delphi ausschließlich. Sie ermöglichen eine sehr hohe Entwicklungsgeschwindigkeit. Setzt man sie auf TQuery oder Ableitungen auf, kann man sehr gut ganz unterschiedliche Aufgaben erledigen, von der Dateneingabe über Datensuche bis hin zu Massenverarbeitung oder Reporting.

Post, Append, (Insert, Delete, ..) kann man m.E. nicht als konkurrente Veranstaltung zu direkten SQL Statements betrachten. Sie sind eher abstrakte und allgemeine Methoden, die einerseits Datenbankspezifika ausblenden, andererseits aber hinterm Vorhang in genau so ein direktes SQL Statement münden, eine hochsprachliche, "elegante" Variante eines direkten SQL Befehls.

Du kannst in einem halben Tag ein einfaches Testprogramm mit einer Handvoll Komponenten zusammen klicken (ohne Code), worin Queries und datensensitive Komponenten ein funktionierends Dateneditierungsprogramm ergeben. Du kannst ausprobieren, wie sich die dahinter liegende Tabellengröße auswirkt. 100, 1000 oder Millionen Datensätze. Du kannst Nachschlagetabellen, DBLookup Felder o.ä. einbauen, das geht alles relativ schnell und straight forward. Und wenn Du das hast, kannst Du leicht nachvollziehen, wie die ganze Schnappmatik für 10 oder 30 oder 100 Tabellen aussehen würde.

Alternativ gibt es eine Menge andere Herangehensweisen. Unter Delphi vielleicht am ehesten ein ORM, ein REST Service oder auch die Komponenten aus den Architect(?) Editionen, mit denen ich mich aber gar nicht auskenne. Hier brauchst Du m.E. ein wenig mehr Anlauf. Es wird mehr Aufwand getrieben, der sich aber auszahlen kann, wenn es um sparsamen Umgang mit Resourcen geht, für hochfrequentierte Multiuser Systeme, Webserver usw.

TTable und Filter würde ich als historische Vorgehensweisen betrachten.

[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:

Zitat von Frickler (Beitrag 1481362)

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.

[TigerLilly]

Zitat:

Zitat von Frickler (Beitrag 1481362)

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:

Zitat von himitsu (Beitrag 1481404)

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:

Zitat von Relic (Beitrag 1481245)

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:

Zitat von freejay (Beitrag 1481519)

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.

[Mavarik]

Naja die DBControls sind ja die "alten" mittlerweile ist ja jedes Control über die LiveBindings bindbar… (Grusel)

Mavarik

[TigerLilly]

Ich kann die Ablehnung von DBControls nicht so ganz nachvollziehen. Sie haben ja alles, was man an Notifications braucht + sonst selbst nachbauen würde. Sie müssen ja nicht direkt an eine Query gehängt werden. Für mich hat das mit Clientdatasets sehr gut funktioniert: TQuery --> TProvider --> TClientdataset Kann man sogar alles schön entkoppeln.

[Frickler]

Zitat:

Zitat von TigerLilly (Beitrag 1481541)

Ich kann die Ablehnung von DBControls nicht so ganz nachvollziehen. Sie haben ja alles, was man an Notifications braucht + sonst selbst nachbauen würde. Sie müssen ja nicht direkt an eine Query gehängt werden. Für mich hat das mit Clientdatasets sehr gut funktioniert: TQuery --> TProvider --> TClientdataset Kann man sogar alles schön entkoppeln.

Mein Reden seit Achtzehnsiebzig.

Ich mache auch alles mit Clientdatasets, aber ohne ständige Verbindung zur Datenbank. Habe mir so Funktionen gebaut, die Provider und Query on the fly erzeugen, die Selektion durchführen, die Daten ins CDS laden und danach die Verbindung trennen. Dann kann man mit den Daten machen, was nötig ist. Sollte geupdatet werden, gibts wieder ne Verbindung zur Datenbank und in einer kurzen Transaktion wird die Datenbank geupdatet.