Einstellungen lesen und "durchreichen" ?

[Mavarik]

Zitat von 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.

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 von Mavarik:

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

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 von jobo:

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

[jobo]

Wenn Arbeitsplätze wechseln oder heterogene Programm- oder Serversysteme bedient werden müssen, macht es auch Sinn, Usereinstellungen auf dem Server zu speichern.
Caching, Compression oder Lazy Loading ist natürlich auch eine effiziente Art, Datenübertragung gering zu halten. Daten zu übertragen, die nicht benötigt werden, ist dennoch nicht effizient, auch wenn ich das Übertragen von Daten möglichst effizient gestalte.
Die Diskussion ist auch etwas müßig, ich glaube Dir ja, dass Dein System gut funktioniert, aber ich habe einfach die Frage des TE aus meiner Sicht beantwortet. Es kommt sehr auf die Umgebung und den Anwendungsfall an. Die sind hier im Thread allerdings unbekannt.
Ich habe eingangs bspw. ein Einzelplatzsystem genannt, bei dem viele Aspekte nicht so schwerwiegend sind. Programmtechnisch muss ich diese Probleme dann u.U. auch nicht berücksichtigen, jenachdem wofür auch bezahlt wird.
Ich hatte vor ein paar Jahren mal das Vergnügen eine fremde Anwendung zu analysieren bzw. zu optimieren (VS C# Fat Client gegen Oracle). Das Ding hat beim Entwickler tadellos funktioniert, im Anwendertest aber total versagt. Schuld war hauptsächlich eine (Fertig)Komponente, glaub so ne Art Kategorienbaum, der scheinbar kaum Daten enthielt. Die Komponente hatte Filter definiert, die lokal angewendet wurden. Die geladene Datenbasis war aber glaub so ca 60 MB.

[Mavarik]

Zitat von jobo:

Es kommt sehr auf die Umgebung und den Anwendungsfall an. Die sind hier im Thread allerdings unbekannt.

Stimmt... Also antworten wir gemäß internem Abkommen mit:

42