Best-Practices Datenbanken in Delphi

[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

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

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.