code refactoring Bilderdatenbank

[bernhard_LA]

unsere Anwendung speichert in einer DB Tabelle mehrere Bilder .
Wenn ich die gesamte Tabelle in den Arbeitsspeicher kopiere dauert dieser Vorgang 30 min, ich belege ca. 8 Gbyte RAM. Fürs praktische Arbeiten also eher ungeeignet. Anzahl der Datensätze ca. 10.000 .... 20.000; Die wesentlichen Informationen zu meinen Bildern stehen in ein paar Textfeldern (String) in meiner Tabelle, der Zugriff geht hier "deutlich" schneller.


Die Idee für Code refactoring : Aufbau einer Query ohne die Bilder und die Bilder dann immer nur bei Bedarf von dem tatsächlich verwendeten Datensatz separat nachladen.

Frage: gibt es einen besseren Lösungsansatz ?

[Delbor]

Hi bernhard_LA

Vor Jahren hab ich mal was mit Access gemacht. Da gibt es sowas wie 'Datenbankseiten'. Nennt sich, wenn ich mich recht erinnere, Pages in VB. Von daher nehm ich an, dass ADO sowas auch kennt.
Gemeint ist damit die Anzahl der Datensätze, die zur Bearbeitung für die Benutzung anderer User gesperrt und aktuell geladen werden. Damit solltest du die Anzahl der Datensätze festlegen können, die in 'einem Rutsch' geladen werden.

In meiner Bildatenbank speichere ich die Bilder ausser in der 'Verwndungsgrösse', also in der Grösse, in der sie letztlich angezeigt werden, auch als Thumbnails. Wenn die Daten zur Navigation oder zur Bearbeitung angezeigt werden sollen, lade ich nur diese Thumbnails. Das Bild in der 'Verwendungsgrösse' wird nur geladen, wenn es grafisch bearbeitet werden soll.
So ein Thumbnail hat ei einer grossen Seitenlänge von 100 Pixeln im Jpegformat gerade mal ca. 1.2 kb...

Gruss
Delbor

[HeZa]

Zitat von bernhard_LA:

unsere Anwendung speichert in einer DB Tabelle mehrere Bilder .
Wenn ich die gesamte Tabelle in den Arbeitsspeicher kopiere dauert dieser Vorgang 30 min, ich belege ca. 8 Gbyte RAM. Fürs praktische Arbeiten also eher ungeeignet. Anzahl der Datensätze ca. 10.000 .... 20.000; Die wesentlichen Informationen zu meinen Bildern stehen in ein paar Textfeldern (String) in meiner Tabelle, der Zugriff geht hier "deutlich" schneller.


Die Idee für Code refactoring : Aufbau einer Query ohne die Bilder und die Bilder dann immer nur bei Bedarf von dem tatsächlich verwendeten Datensatz separat nachladen.

Frage: gibt es einen besseren Lösungsansatz ?

Warum will man 20000 Bilder laden?
Gibt es irgendeinen User der sich 20000 Bilder ansehen will?
Oder ist es eine automatische Verarbeitung?

Falls es eine interaktive Anwendung ist:
- Lass den User Kriterien eingeben welche Bilder er sehen möchte und lade nur diese
- Lass den User entscheiden, ob er die Bilder mit laden möchte (und bereit ist zu warten)

Ciao Heinz

[Perlsau]

Zitat von bernhard_LA:

Die Idee für Code refactoring : Aufbau einer Query ohne die Bilder und die Bilder dann immer nur bei Bedarf von dem tatsächlich verwendeten Datensatz separat nachladen. Frage: gibt es einen besseren Lösungsansatz ?

Ja, den gibt es:

• Die Bilder in eine eigene Tabelle auslagern. Ich hab nämlich auch so eine Datenbank, allerdings mit SQL-Server, und da hatte ich dasselbe Problem: Das Blättern (scrollen) in den Datensätzen war sehr träge, allein schon die Darstellung der zugehörigen Texte im DBGrid dauerte eine gefühlte Ewigkeit. Jetzt blende ich bei Bedarf ein Formular ein, das im OnShow überhaupt erst eine Verbindung zur der Bild-Tabelle aufbaut und das originale Bild anzeigt. In der Ursprungstabelle halte ich stattdessen Thumbnails vor (100x100 oder kleiner), die passen sogar in eine Tabelle, wenn man das will.
• Nicht alles auf einmal vom Server holen. Je nach DB-Komponenten kannst du einstellen, wie viele Records jeweils vom Datenbankserver angefordert werden.
• Bei großen Tabellen bzw. Tabellen mit Blobfeldern arbeite ich allermeist mit Filter bzw. Where-Klausel, so daß niemals alle Datensätze auf einmal gefetched werden müssen.

[nahpets]

Bei ADO gibt es die CursorLocation.

Steht die bei Dir auf clUseServer oder auf clUseClient.
Beim Zweiten wird alles auf den Client "geholt", also erstmal alles aus der Abfrage muss durch die Leitung. Bei clUseServer sollte das nicht der Fall sein. dann bekommt man (nach meiner Erfahrung) nur dass, was gerade aktuell auf dem Client benötigt wird.

Ein kurzes Experiment sollte hier recht schnell Klarheit über eine mögliche Verbesserung bringen.

Bei Abfragen und Tabellen gibt es bei ADO auch noch CursorType. Hier können unterschiedliche Werte auch zu deutlichen Veränderungen im Laufzeitverhalten führen.

Ja nach Datenbank sind unterschiedliche Kombinationen sinnvoll. Hier versuche ich es immer per "Try and Error". 'ne sinnvolle "Richtlinie" habe ich bisher nicht finden können.