Datenbank für schnelle Bilder, Vorschläge bitte.

[jobo]

Zitat von KodeZwerg:

Wobei ich da auch gerade am umstrukturieren bin und alles auf Firebird.pas als Unterbau/Schnittstelle nehmen möchte.

Man muss sich nicht ohne Not und namentlich auf eine DB festnageln. Ich glaube das Datenmodell und der Zugriff Delphi seitig benötigen bei dem Projekt keine Firebird spezifischen Funktionen.
Also wie wär's mit einem klassischen Datenmodul? Oder data.pas oder ..

[haentschman]

Moin...
!!! Eigenwerbung:

Zitat:

Wobei ich da auch gerade am umstrukturieren bin und alles auf Firebird.pas als Unterbau/Schnittstelle nehmen möchte.

Es gibt noch eine Variante um die SQL Statements nicht in den Komponenten (Query) zu speichern sondern extern als Ressource...macht den QT übersichtlicher.
https://www.delphipraxis.net/49505-s...einbinden.html
https://www.delphipraxis.net/190316-...e-creator.html

Persönlich bevorzuge ich eine separate Unit für den Datenbankzugriff statt dem Verteilen der SQL Statements auf die gesamte Anwendung! Die Anwendung muß nur die eine Unit kennen. Alle greifen auf die in der Unit enhaltenen Prozeduren zurück. Ob das nun ein Datenmodul, eine Klasse oder ein Interface ist ist jedem selbst überlassen.

[Codehunter]

Zitat von haentschman:

Es gibt noch eine Variante um die SQL Statements nicht in den Komponenten (Query) zu speichern sondern extern als Ressource...macht den QT übersichtlicher.

Irgendwie habe ich das selbe vor langer Zeit auch schon angefangen. Das ergibt sich ab einer bestimmten Programmkomplexität und dem drölfzigsten DB-Struktur-Update mit anschließender Query-Such-und-Anpass-Orgie im Quelltext ganz automatisch. Allerdings speichere ich die Queries nicht als Ressourcen sondern in einer Name-Value-Datenstruktur außerhalb des Kompilats. Aber das wäre sicherlich Stoff für einen separaten Thread.

[jobo]

Zitat von Codehunter:

Allerdings speichere ich die Queries nicht als Ressourcen sondern in einer Name-Value-Datenstruktur außerhalb des Kompilats.

Oder in einer Datenbank?

[Codehunter]

Zitat von jobo:

Zitat von Codehunter:

Allerdings speichere ich die Queries nicht als Ressourcen sondern in einer Name-Value-Datenstruktur außerhalb des Kompilats.

Oder in einer Datenbank?

Dann hättest du zumindest einen Query wieder im Quelltext ^^ Aber ein lustiger Ansatz wärs schon, eine Datenbank die ihre eigenen Queries vorhält. Da ist der Weg nicht mehr weit zu selbstmodifizierenden Strukturen

[mkinzler]

Das habe ich auch schon gemacht. Komplexe Abfragen gehören eh in die DB (in Form von Stored Procedures)

[haentschman]

Zitat:

Allerdings speichere ich die Queries nicht als Ressourcen sondern in einer Name-Value-Datenstruktur außerhalb des Kompilats.

Richtig...wichtig ist nur die SQL aus den Komponenten herauszuholen und eine Suchorgie zu verhindern.

[Codehunter]

Zitat von mkinzler:

Das habe ich auch schon gemacht. Komplexe Abfragen gehören eh in die DB (in Form von Stored Procedures)

Ich persönlich mag Stored Procedures nicht so richtig. Am Anfang hat man alles sauber und ordentlich aber schon nach kurzer Zeit vermehren sich die Dinger wie die Karnickel, weil man A) weiter entwickeln und B) rückwärtskompatibel sein will. Also macht man mit jeder Programmversion auch eine neue Version der Stored Procedure, falls sie von Änderungen betroffen ist und die alte SP bleibt stehen wie sie war. Aber das mag ein fallspezifisches Problem sein.

[jobo]

[ot]Der ziemlich naheliegende Weg wäre wohl Nutzung von Views. Dann braucht die App nur Namen zu kennen (oder aus der DB zu laden oder aus der INI/Registry).
Wir machen das in einigen Anwendungen so, dass ein komplettes Dictionary für die App, mit Viewname, Where Clauses, Spalten(Namen), wenn nötig DML usw. Masken spezifisch in der DB liegt.
Die Selects in der Anwendung werden dann dynamisch zusammengebaut (meist reicht der bloße Zugriff auf den View plus aktuelle ID(s) als Einschränkung), die Views liefern dann z.B. auch Dateninhalte gemäß Anwender - Spracheinstellung.
[/ot]

[KodeZwerg]

Ok, wer mal lachen mag schaue sich meine ersten Geh-Versuche an worauf irgendwie alles spätere Aufbaut:

Delphi-Quellcode:

Function CheckDB (const sName: String; const wCRC: Word) : Boolean;
type
  MyRec = packed record
    Name: String;
    CRC: Word;
  end;
var
  MyDB: MyRec;
  MyDBFile: File OF MyRec;
begin
  Result := False;
  AssignFile(MyDBFile, '.\test.db');
  Reset(MyDBFile);
  try
    while not EOF(MyDBFile) do
    begin
      Read(MyDBFile, MyDB);
      with MyDB do
      begin
        if ((LowerCase(Name) = LowerCase(sName)) and (CRC = wCRC)) then
        begin
          Result := True;
          Exit;
        end;
      end;
    end;
  finally
   CloseFile(MyRead);
  end;
end;

Nicht vom Stuhl fallen vor lachen