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

[Delphi.Narium]

Wenn ich mit NAME und CRC suche, finde ich den Satz nur, wenn beide übereinstimmen. Haben sich die Daten zwischenzeitlich geändert, bekomme ich mit der Abfrage auf NAME und CRC kein Ergebnis und muss daher davon ausgehen, dass ein neuer Datensatz angelegt werden muss. Es entsteht dann eine Namensdublette.

[mkinzler]

Zitat:

Zitat von Delphi.Narium (Beitrag 1400557)

Wenn ich mit NAME und CRC suche, finde ich den Satz nur, wenn beide übereinstimmen. Haben sich die Daten zwischenzeitlich geändert, bekomme ich mit der Abfrage auf NAME und CRC kein Ergebnis und muss daher davon ausgehen, dass ein neuer Datensatz angelegt werden muss. Es entsteht dann eine Namensdublette.

Nein, da ein

SQL-Code:

insert or update

dass ja erkennt!

[KodeZwerg]

@Delphi.Narium, vorerst ist die einzige statische verwendung der name (Datei.xyz zum Beispiel) aber mit den if then else's komme ich klar! Vielen Dank nochmal!

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1400544)

Ist eine name vorhanden wird der crc und die Bilder upgedatet sonst wird ein neuer DS erzeugt.

Na wenn er Recht hat, hat er recht!

Gruß
K-H

[Codehunter]

Der KodeZwerg ist ja ein Hansdampf in allen Gassen :lol: Wenn ich deine letzten Fragen so Revue passieren lasse, dann würde mich schon interessieren an was du da eigentlich dran bist...

Zum Thema: Ist MongoDB nicht für genau solche Anwendungsfälle erfunden worden? Dokumentenbasierte Datenbank und so?

[KodeZwerg]

Zitat:

Zitat von Codehunter (Beitrag 1400659)

Wenn ich deine letzten Fragen so Revue passieren lasse, dann würde mich schon interessieren an was du da eigentlich dran bist...

Wie meinst Du das? Andere von mir Erstellte Threads haben nichts mit diesem Thema gemein.

Zitat:

Zitat von Codehunter (Beitrag 1400659)

Ist MongoDB nicht für genau solche Anwendungsfälle erfunden worden?

Das weiß ich nicht, ich bin DB Neuling und froh das Firebird relativ leicht zu verstehen ist.
edit
Wobei ich da auch gerade am umstrukturieren bin und alles auf Firebird.pas als Unterbau/Schnittstelle nehmen möchte.

[jobo]

Zitat:

Zitat von KodeZwerg (Beitrag 1400661)

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...:P
!!! Eigenwerbung: 8-)

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. :thumb:
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. :wink:

[Codehunter]

Zitat:

Zitat von haentschman (Beitrag 1400682)

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:

Zitat von Codehunter (Beitrag 1400689)

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

Oder in einer Datenbank?
:)

[Codehunter]

Zitat:

Zitat von jobo (Beitrag 1400690)

Zitat:

Zitat von Codehunter (Beitrag 1400689)

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 8-)

[mkinzler]

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

[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 :thumb:

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

[Neutral General]

Zitat:

Zitat von KodeZwerg (Beitrag 1400700)

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

:?::?::?:

Was hat das mit einer Datenbank zu tun?

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1400696)

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]

[haentschman]

Zitat:

Nicht vom Stuhl fallen vor lachen

..das ist eher ein Fall für Küchenrolle, weil Taschentücher nicht reichen. :zwinker: Man muß nicht alles selber machen...

[Codehunter]

Zitat:

Zitat von haentschman (Beitrag 1400705)

Zitat:

Nicht vom Stuhl fallen vor lachen

..das ist eher ein Fall für Küchenrolle, weil Taschentücher nicht reichen. :zwinker: Man muß nicht alles selber machen...

Ich finds nicht zum Lachen. Hat KodeZwerg vielleicht die gesamte Datenbankabstraktion und DbAware von Delphi noch gar nicht entdeckt?

EDIT:

Zitat:

Zitat von jobo (Beitrag 1400704)

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

Views sind nicht schlecht. Habe ich in einigen Fällen bei MariaDB benutzt. Allerdings mit der Einschränkung, dass sie bei umfangreicherer Parametrierung schnell unhandlich werden.

[jobo]

Zitat:

Zitat von KodeZwerg (Beitrag 1400700)

Ok, wer mal lachen mag schaue sich meine ersten Geh-Versuche an worauf irgendwie alles spätere Aufbaut:Nicht vom Stuhl fallen vor lachen :thumb:

Hör mal auf immer Asche auf Dein Haupt zu streuen.

Was machst Du mit Assign File?
Das hat da nichts zu suchen. Du willst nicht auf eine proprietär (von Dir) befüllte Datei zugreifen, sondern per Treiber auf ein bekanntes DB Format.
Bei Firebird verwendet man dazu eine DBConnection mit Angabe des Pfades der Datenbankdatei.

Wie wärs, wenn Du Dir mal ein DB Tutorial anschaust?

[Neutral General]

Sorry ich kanns mir nicht verkneifen..
10 Seiten riesige technische Diskussionen wie man das am besten umsetzt und dem Threadersteller fehlt das grundlegende Verständnis was überhaupt eine Datenbank ist und hat scheinbar von den 10 Seiten kein Wort verstanden. Diesen Quelltext von ihm auf der 1. oder 2. Seite wäre vllt noch OK gewesen und man hätte die nächsten 8 Seiten dazu benutzen können ihm zu erklären und zu helfen wie er eine richtige Datenbank erstellt und anbindet :roll:

[KodeZwerg]

Ich schrieb ja mehrmals das ich ein DB Neuling bin und kenne mich da Null aus.
Nun habe ich wenigstens Ansatzweise mini-Wissen um das zu erledigen was ich wollte.
Jetzt trenne ich mich von der UIB Komponente um rein Nativ zu arbeiten und um das ganze Firebird besser zu verstehen.
Das letztere ist eigentlich mein Hauptgrund, eh ich in der Komponente herausgefunden habe das es einen Datenbank-Designer und all sowas gibt, das hat gedauert wenn man davon null Ahnung hat :)
In den Built-In Delphi DB Komponenten habe ich bis auf MyBase noch nichts angefasst.

[Neutral General]

Zitat:

Zitat von KodeZwerg (Beitrag 1400711)

Jetzt trenne ich mich von der UIB Komponente um rein Nativ zu arbeiten und um das ganze Firebird besser zu verstehen.

Nein, tus nicht. Abgesehen davon, dass "nativ" was anderes ist als du denkst. Nativ wäre die Firebird-API direkt zu benutzen,
nicht Records mit AssignFile in eine Datei zu schreiben und auszulesen.
Aber selbst die Firebird-API direkt zu benutzen ist vollkommen unnötig und du machst dir damit nur das Leben schwer.
Und du wirst Firebird auch nicht besser verstehen wenn du die API direkt benutzt.
Du solltest erst mal Datenbanken im Allgemeinen verstehen. Falls du irgendwann SQL und Datenbankmeister bist und Interesse hast dir die Innereien von Firebird anzuschauen (was eigentlich nicht notwendig oder von Vorteil ist falls du nicht selbst an FB oder einem DBMS arbeiten willst) dann kannst du dir die Firebird-API ja mal anschauen.

Lad dir Firebird runter, lad dir IBExpert runter und (falls dein Delphi keine Datenbank-Komponenten hat) besorg dir Komponenten für den Zugriff auf (Firebird-)Datenbanken.
Dann benutzt du die Connection- und Query-Komponenten um dich mit der Datenbank zu verbinden und zu kommunizieren.

[jobo]

Zitat:

Zitat von Neutral General (Beitrag 1400710)

.. hat scheinbar von den 10 Seiten kein Wort verstanden..

So würde ich das nicht sagen, es war wenig die Rede von konkretem Programmcode, mehr (geeigneten) Datenbanken, Datenmodell, Performance usw.
Was dabei nun rausgekommen ist, finde ich gar nicht so überraschend, wenn man z.B. mit einer freien Delphi Version ohne DB Komponenten startet.
Wer Jahrzehnte mit den Delphi Komponenten mitgewachsen ist, hat natürlich gut lachen. Wieviel gab es damals bei Delphi 3, so 5 oder 6 Reiter mit den Standard GUI und DB Komponenten, Reporting, ..fertig. Sehr übersichtlich.
Ich kann mich noch gut erinnern, wie ich mich früher geärgert habe, wenn ich irgendwas zu Fuß programmiert hatte und später fertige Funktionen / Komponenten dafür fand. Hat mir sicher nicht geschadet. Außer der Sache mit der Lebenszeit, jaja..

[mkinzler]

Es ist kein kompletter Code vorhanden, über die Beiträge verteilt sollte der benötigte Code aber da sein.
Es scheint aber auch am grundlegenden Verständnis an der Funktion eines DBMS zu mangeln. Die Lösung mit der typisierten Datei hat überhaupt nichts mit einer Datenbanklösung zu tun.
Natürlich ist Selbermachen gut für das Lernen, aber zur Lösung des bestehenden Problems imho nicht unbedingt geeignet.

[jobo]

Ja, ist doch okay, deswegen habe ich ja ein DB Tutorial empfohlen..
Was ist das Fazit solcher Beiträge wie "Küchenrolle statt Taschentuch"? Das ist doch Kindergartenniveau.

[Codehunter]

Zitat:

Zitat von jobo (Beitrag 1400716)

Ich kann mich noch gut erinnern, wie ich mich früher geärgert habe, wenn ich irgendwas zu Fuß programmiert hatte und später fertige Funktionen / Komponenten dafür fand. Hat mir sicher nicht geschadet. Außer der Sache mit der Lebenszeit, jaja..

Was soll ich denn da sagen? Wie viel Entwicklungszeit ist z.B. in die Dateiroutinen von DelphiWorks damals geflossen, was heute größtenteils alles von TFile und TDirectory erschlagen wird. Andererseits sag ich mir: Wenn man alles fertig vorverdaut bekommt, lernt man selbst nichts mehr über die Grundlagen. (OT: Ich hör U30er mit ihren Smartphones von "Speicher" reden und kennen nicht mal den Unterschied zwischen RAM und Flash)

[Neutral General]

Zitat:

Zitat von jobo (Beitrag 1400716)

Zitat:

Zitat von Neutral General (Beitrag 1400710)

.. hat scheinbar von den 10 Seiten kein Wort verstanden..

So würde ich das nicht sagen, es war wenig die Rede von konkretem Programmcode, mehr (geeigneten) Datenbanken, Datenmodell, Performance usw.
Was dabei nun rausgekommen ist, finde ich gar nicht so überraschend, wenn man z.B. mit einer freien Delphi Version ohne DB Komponenten startet.

Also laut Profil hat er 10.2 Professional.
Natürlich war nicht die Rede von konkretem Programmcode. Aber wenn man über geeignete Datenbanken/Datenmodell, Performance redet und dann der Quellcode rauskommt den er gepostet hat, dann finde ich das schon überraschend.
Vor allem weil er ja laut eigener Aussage sich auch über die Dinge die hier besprochen wurden informiert hat.
Oder kurz gesagt: Hätte er etwas von den 10 Seiten verstanden wäre nicht dieser Code dabei rausgekommen.

An KodeZwerg: Das was ich in den letzten (und in diesem) Posts geschrieben hab ist nicht böse gemeint.
Du musst einfach ganz von vorne anfangen und ein Einsteiger-DB-Tutorial durcharbeiten. Jeder hat mal da angefangen aber es ärgert mich halt, dass es erst nach 10 Seiten Diskussion rauskommt das du absolut keine Ahnung von Datenbanken hast. Du hättest da direkt am Anfang sagen müssen dass du von dem was hier diskutiert wird nur Bahnhof verstehst. Dann hätte man direkt an der richtigen Stelle ansetzen können mit der Hilfe statt über eine optimale Struktur und Performance zu reden mit dem du momentan eh nichts anfangen kannst.

[mkinzler]

Zitat:

Was ist das Fazit solcher Beiträge wie "Küchenrolle statt Taschentuch"? Das ist doch Kindergartenniveau.

Da gebe ich Dir recht. Ich glaube aber nicht dass es so gemeint war, wie es rüberkommt.

Delphi-Quellcode:

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

Die View-Unterstützung in FB ist nicht so toll. Dafür kann man eine SP wie ein View verwenden. Deshalb werden diese da auch oft verwendet.

[KodeZwerg]

Ähhmm... da besteht ein Missverständnis.
Das CheckDB entstammt dem History Ordner als ich noch bevor ich hier fragte Eigentests durchführte.
Katastrophale Tests aber nur so wird man schlauer, schrieb hier auch mal jemand.
Missverständnis #2 wenn ich Nativ schreibe meine ich mit Hilfe der Firebird.pas Datei die bei Firebird dabei gelegt ist und mir Api-Header zur Verfügung stellt.
Danke für den Tipp.

[Neutral General]

Zitat:

Zitat von mkinzler (Beitrag 1400725)

Delphi-Quellcode:

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

Die View-Unterstützung in FB ist nicht so toll. Dafür kann man eine SP wie ein View verwenden. Deshalb werden diese da auch oft verwendet.

Was ist das Problem mit der View-Unterstützung? Was genau ist nicht so toll?
Man kann Views Trigger verpassen und dafür sorgen dass sie sich exakt wie Tabellen verhalten und im Hintergrund kann man selektieren was man will.
Was fehlt denn da noch was hilfreich wäre?

[Neutral General]

Zitat:

Zitat von KodeZwerg (Beitrag 1400726)

Ähhmm... da besteht ein Missverständnis.
Das CheckDB entstammt dem History Ordner als ich noch bevor ich hier fragte Eigentests durchführte.
Katastrophale Tests aber nur so wird man schlauer, schrieb hier auch mal jemand.

Okay das beruhigt mich :P

Zitat:

Zitat von KodeZwerg (Beitrag 1400726)

Missverständnis #2 wenn ich Nativ schreibe meine ich mit Hilfe der Firebird.pas Datei die bei Firebird dabei gelegt ist und mir Api-Header zur Verfügung stellt.
Danke für den Tipp.

Tus nicht. Das ist wie ich weiter oben schon geschrieben hab total unnötige Arbeit.
Geh über ganz normale Datenbank-Komponenten/Klassen die bei deiner Delphi-Version dabei sind.

[Codehunter]

Vielleicht ist ein Video-Tutorial für den Anfang nicht verkehrt? Schon etwas älter und noch mit der alten D7-IDE, aber die Grundlagen sind hier schön erklärt anhand von Firebird, was ja zuvor hier schon angesprochen wurde.

[Codehunter]

Also was Datenbanken betrifft hast du mit Delphi zwar das richtige Werkzeug, gehst die Sache aber vom falschen Ende her an. Delphi hat vieles an Bord um dir die Grundlagenforschung abzunehmen. Wie man auf Netzwerk- oder Dateiebene mit dem Datenbankserver spricht, braucht dich eigentlich gar nicht interessieren. In vielen Fällen klickt man sich die Verbindung per Maus zusammen. Viel wichtiger ist das Datenbankmodelling. Das klang ganz am Anfang hier an: Willst du große Datenmengen binär speichern, musst du dir Gedanken um die Verwaltung dessen machen.

Binär- oder Rohdaten sind kaum bis gar nicht indizierbar, weshalb du zusätzliche Metadaten erzeugen und speichern musst. Im Prinzip das, was du mit deinem "Aufreger-Codeschnipsel" mehr oder weniger zu Fuß machen wolltest. Als Schnelleinstieg:

https://www.delphi-treff.de/tutorials/datenbanken/
http://www.delphitutorials.de/node/25
http://docwiki.embarcadero.com/RADSt...d_LiveBindings

[KodeZwerg]

Danke Codehunter für Links, ich werd auch beherzigen was Ihr so alles geschrieben habt, lernen lernen lernen, bin dabei! :thumb:

[p80286]

Dann möchte ich doch ein bischen Provozieren.
Es ist für mein Programm vollkommen egal ob die Daten in einer typisierten Datei oder in einer Datenbank liegen. Und wenn das Programm gut geschrieben ist, dann ist der Zugriff auf eine typisierte Datei ohne großen Aufwand gegen den Zugriff auf eine DB austauschbar.
Wenn diese Schnittstelle definiert ist, dann kann man sich Gedanken über die DB, die Ablage der Querytexte und die optimalen Indexdefinitionen machen. Und natürlich die Komponenten die man benötigt um an die notwendigen Daten zu kommen.

Gruß
K-H

[jobo]

Jetzt willst Du die Verwirrung komplett machen?
;)

Vielleicht könnte ich mich noch mit einem REST System anfreunden, aber Persistenzsysteme würde ich nicht nachbauen und auch nicht ohne Not einsetzen.