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

Zitat:

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

Das entscheidet eigentlich jeder für sich. Du kannst eigentlich nur die verschiedenen Varianten anschauen und entsprechend deiner Aufgabe entscheiden.
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...

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

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

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