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.

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

[Mavarik]

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

Mavarik