AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Best-Practices Datenbanken in Delphi

Best-Practices Datenbanken in Delphi

Ein Thema von Relic · begonnen am 19. Jan 2021 · letzter Beitrag vom 1. Feb 2021
Antwort Antwort
Seite 1 von 3  1 23   
Relic

Registriert seit: 22. Feb 2014
9 Beiträge
 
#1

Best-Practices Datenbanken in Delphi

  Alt 19. Jan 2021, 21:31
Datenbank: DBISAM • Version: . • Zugriff über: direkt
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!
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Best-Practices Datenbanken in Delphi

  Alt 19. Jan 2021, 21:40
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Relic

Registriert seit: 22. Feb 2014
9 Beiträge
 
#3

AW: Best-Practices Datenbanken in Delphi

  Alt 19. Jan 2021, 21:50
@Stahli:

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

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: Best-Practices Datenbanken in Delphi

  Alt 19. Jan 2021, 22:48
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...
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.275 Beiträge
 
Delphi 12 Athens
 
#5

AW: Best-Practices Datenbanken in Delphi

  Alt 20. Jan 2021, 06:41
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

  Mit Zitat antworten Zitat
Benutzerbild von Jasocul
Jasocul

Registriert seit: 22. Sep 2004
Ort: Delmenhorst
1.330 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Best-Practices Datenbanken in Delphi

  Alt 20. Jan 2021, 08:23
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.
Peter

Geändert von Jasocul (20. Jan 2021 um 08:26 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#7

AW: Best-Practices Datenbanken in Delphi

  Alt 20. Jan 2021, 22:04
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.
Gruß, Jo
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
1.172 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: Best-Practices Datenbanken in Delphi

  Alt 21. Jan 2021, 08:55
"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.
  Mit Zitat antworten Zitat
Frickler

Registriert seit: 6. Mär 2007
Ort: Osnabrück
557 Beiträge
 
Delphi XE6 Enterprise
 
#9

AW: Best-Practices Datenbanken in Delphi

  Alt 21. Jan 2021, 19:10
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...
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.364 Beiträge
 
Delphi 10.3 Rio
 
#10

AW: Best-Practices Datenbanken in Delphi

  Alt 22. Jan 2021, 10:02
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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:15 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz