Einstellungen lesen und "durchreichen" ?

[khh]

Hallo zusammen,
ich überlege gerade, ob es Sinn macht diverse (Einstellungs)-Werte aus der Datenbank konzentriert im "Startformular" zu lesen und an die einzelnen anderen Formulare und Klassen "durchzureichen".
Oder sollen die Werte in der jeweiligen Klasse selbst aus der DB gelesen werden.

Was ist wohl effizienter?
Danke für eure Meinungen.

Gruss KH

[p80286]

Wie üblich, es kommt darauf an. Wenn der Anwender nur mal kurz die Versionsinformation benötigt, und dann warten muß, bis die letzte exotische Funktion das 42te Druckformat geladen hat, das kommt gut. Auf der anderen Seite, jeder DB-Aufruf kostet, egal wieviele Daten durch die Leitung gehen, darum so viele Daten wie möglich pro Aufruf abholen.
Mein Ansatz, zuerst das absolut notwendige, und während der Benutzer noch staunt, in einem eigenen thread den Rest abholen.

Gruß
K-H

[Mavarik]

Von welchen Daten-"Mengen" reden wir den...

Ich lade immer alle Einstellungen beim Start...

Das macht blub und alles ist da... Nicht Messbar.

Und natürlich NICHT im Formular...

Mavarik

[jobo]

Also wenn es um Resourceneffizienz geht, können 100, 1000 oder 10000 Einstellungen unproblematisch sein, wenn es ein Einzelplatzsystem ist (mit lokaler Datenhaltung). Von Effizienz kann man trotzdem nicht reden.
Rechnet man sowas mal Anzahl der Nutzer und mal Anzahl der Starts pro Tag, kann der Server schon mal stottern.
Bei Schichtbeginn ist dann u.U. die berühmte "Tasse Kaffee" fällig. 100 oder so User die sich pünktlich um 8:30 Uhr anmelden, ein Traum.

Laden nach Bedarf halte ich für besser. Es dürfte auch dem Code und der Codelesbarkeit gut tun. Ob man es dann für jeden i-Punkt macht oder je Maske, ist ein weiteres Detail.

[BUG]

Also im Prinzip könntest du ein Singleton oder ein durchgereichtes Objekt verwenden, das die Einstellungen faul nachlädt.
Das faule Nachladen brauchst du gar nicht sofort implementieren, wenn du ein ordentliches Interface definierst. Lade die Einstellungen erst einmal ganz und implementiere das andere wenn du es brauchst.

Auf jeden Fall würde ich das Laden der Einstellungen im Code von der Stelle entkoppeln, wo die Einstellungen benutzt werden.

[Perlsau]

Ich mach das meistens so: Beim Programmstart meiner Projekte (die mit Frames arbeiten), werden lediglich diejenigen Einstellungen aus der DB gelesen, die sozusagen global gültig sind wie Datenbankdatei, Benutzer-Id, Berechtigungs-Level, Fenstergröße und -position und dergleichen. Beim Aufruf der diversen Frames werden die Einstellungen für den jeweiligen Frame im Code der Frame-Unit ausgelesen. Wenn der Frame z.B. ein DBGrid beinhaltet, werden beim Erzeugen des Frames – bei meinen "größeren" Projekten werden Frames ressourcenschonend stets erneut instanziiert, bevor sie angezeigt werden, und nach dem Ausblenden wieder freigegeben – auch immer gleich die Einstellungen geladen und beim Zerstören wieder zurückgeschrieben. Beispiel zum Einstellen von DBGrid-Spaltenbreiten:

Delphi-Quellcode:

// ---------- Einstellungen lesen ---------- Privat
Procedure TFrame_Partner.EinstellungenLesen;
Var
  i : Integer;
  Aus : String;
begin
  For i := 0 To DBGrid_Partner.Columns.Count -1 Do
  Begin
    Aus := IntToStr(i);
    If i < 10 Then Aus := '0' + Aus;
    Aus := 'PARTNER_' + Aus;
    DBGrid_Partner.Columns[i].Width := DatMod.Qset_BTab.FieldByName(Aus).AsInteger;
  End;
  DBGrid_Partner.SetFocus;
end;

// ---------- Einstellungen schreiben ------ Privat
Procedure TFrame_Partner.EinstellungenSchreiben;
Var
  i : Integer;
  Aus : String;

begin
  DatMod.Qset_BTab.Edit;
  For i := 0 To DBGrid_Partner.Columns.Count -1 Do
  Begin
    Aus := IntToStr(i);
    If i < 10 Then Aus := '0' + Aus;
    Aus := 'PARTNER_' + Aus;
    DatMod.Qset_BTab.FieldByName(Aus).AsInteger := DBGrid_Partner.Columns[i].Width;
  End;
  DatMod.Qset_BTab.Post;
end;

// ---------- Einblenden ------------------- Public
Procedure TFrame_Partner.Einblenden;
begin
  Self.Align   := alClient;
  Self.Visible := True;
  EinstellungenLesen;
end;

// ---------- Ausblenden ------------------- Public
Procedure TFrame_Partner.Ausblenden;
begin
  EinstellungenSchreiben;
  Self.Align   := alNone;
  Self.Visible := False;
end;

Nachdem von der Mainform aus das jeweilige Frame-Objekt erzeugt worden ist, wird die Einblenden-Methode aufgerufen, vor dem Zerstören des Frames die Ausblenden-Methode.

[Mavarik]

Zitat:

Zitat von jobo (Beitrag 1299835)

Also wenn es um Resourceneffizienz geht, können 100, 1000 oder 10000 Einstellungen unproblematisch sein, wenn es ein Einzelplatzsystem ist (mit lokaler Datenhaltung). Von Effizienz kann man trotzdem nicht reden.
Rechnet man sowas mal Anzahl der Nutzer und mal Anzahl der Starts pro Tag, kann der Server schon mal stottern.
Bei Schichtbeginn ist dann u.U. die berühmte "Tasse Kaffee" fällig. 100 oder so User die sich pünktlich um 8:30 Uhr anmelden, ein Traum.

Laden nach Bedarf halte ich für besser. Es dürfte auch dem Code und der Codelesbarkeit gut tun. Ob man es dann für jeden i-Punkt macht oder je Maske, ist ein weiteres Detail.

10000 Einstellungen... Für ein Programm... Von mir aus nehmen wir das mal an... Was sind das?

Boolean? Byte? Integer? Mal nen String?

Lass die 10000 Einstellungen mal 50KB sein... Die lese ich auch von einem Server gerne von 100 Leuten gleichzeitig...

Ohne das ich auch nur eine Verzögerung merken würde...

[Perlsau]

Zitat:

Zitat von Mavarik (Beitrag 1299857)

Ohne das ich auch nur eine Verzögerung merken würde...

:thumb: Da geht's nun wirklich nicht um das, was man als große Datenmengen bezeichnen könnte.

[jobo]

Das können internationalisierte Labels von ein paar hundert Masken / Grids sein, Spaltenbreiten, Formatmasken, Lookupdefinitionen, etc. pp., diese Daten können individuell also pro user unterschiedlich sein.
Das ganze kann ich "schlechten" Netzen stattfinden, die auch von anderen Programmen zugemüllt werden und technisch veraltet sind.
Und es gibt auch Unternehmen, die mehr als 100 Mitarbeiter beschäftigt haben.
Diese Daten müssen vom Server auch zusammengesucht werden, bevor sie dann durchs Netz gehen.
Ich habe für mich noch nie die Bytes zusammenrechnen müssen, weil es noch keinen Bedarf gab.
Wie auch immer, es ging um Effizienz. Alles auf einen Schlag zu laden ist nicht effizient.

[Mavarik]

Zitat:

Zitat von jobo (Beitrag 1299863)

Wie auch immer, es ging um Effizienz. Alles auf einen Schlag zu laden ist nicht effizient.

User definierte Einstellungen werden doch nicht auf dem Server gespeichert, sondern beim User...

Was bedeutet Effizienz...?
Wenig Netzwerk Belastung oder wenig nachladen?
Wenig Programmcode?
Wenig Memory?
Einfache Programmierung?

Ich kann für alle Einstellungen für jedes Feld ein Feld in einer Datenbank reservieren...
Oder ich nehme mir einen netten Record, schreibe den in einen gepackten Stream und dann in ein Blob-Feld alles auf einmal...
Die Userdaten schreibe ich in das User-Datenverzeichnis mit der gleichen Routine gepackt weg...

Fertig...

Wahrscheinlich dauert das öffnen der Datenbank länger als das lesen des blob-Feldes...