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 2 von 3     12 3   
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.399 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Best-Practices Datenbanken in Delphi

  Alt 22. Jan 2021, 12:00
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
896 Beiträge
 
Delphi 10.3 Rio
 
#12

AW: Best-Practices Datenbanken in Delphi

  Alt 22. Jan 2021, 12:15
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.
  Mit Zitat antworten Zitat
Lemmy

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

AW: Best-Practices Datenbanken in Delphi

  Alt 22. Jan 2021, 13:51
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
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.949 Beiträge
 
Delphi 2010 Enterprise
 
#14

AW: Best-Practices Datenbanken in Delphi

  Alt 23. Jan 2021, 05:55
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)
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.024 Beiträge
 
Delphi 10.3 Rio
 
#15

AW: Best-Practices Datenbanken in Delphi

  Alt 24. Jan 2021, 14:07
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
  Mit Zitat antworten Zitat
Benutzerbild von scrat1979
scrat1979

Registriert seit: 12. Jan 2007
Ort: Sulzbach a.d. Murr
1.016 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: Best-Practices Datenbanken in Delphi

  Alt 24. Jan 2021, 14:30
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.
Michael Kübler

Geändert von scrat1979 (24. Jan 2021 um 14:35 Uhr)
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.624 Beiträge
 
Delphi 10.3 Rio
 
#17

AW: Best-Practices Datenbanken in Delphi

  Alt 25. Jan 2021, 11:59
@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]
Andreas
#PerfMatters

Geändert von QuickAndDirty (25. Jan 2021 um 12:12 Uhr)
  Mit Zitat antworten Zitat
freejay

Registriert seit: 26. Mai 2004
Ort: Nürnberg
235 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: Best-Practices Datenbanken in Delphi

  Alt 25. Jan 2021, 14:27
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.
[Delphi 10.4.1 Sydney Enterprise; Win10; MySQL; VCL]
  Mit Zitat antworten Zitat
DasWolf

Registriert seit: 7. Jun 2016
Ort: Neubrandenburg
70 Beiträge
 
Delphi 10.1 Berlin Professional
 
#19

AW: Best-Practices Datenbanken in Delphi

  Alt 25. Jan 2021, 14:41
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?
  Mit Zitat antworten Zitat
freejay

Registriert seit: 26. Mai 2004
Ort: Nürnberg
235 Beiträge
 
Delphi 10.4 Sydney
 
#20

AW: Best-Practices Datenbanken in Delphi

  Alt 25. Jan 2021, 16:00
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.
Miniaturansicht angehängter Grafiken
hierarchische-daten.jpg  
[Delphi 10.4.1 Sydney Enterprise; Win10; MySQL; VCL]
  Mit Zitat antworten Zitat
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 +2. Es ist jetzt 19:18 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf