Einzelnen Beitrag anzeigen

DSCHUCH

Registriert seit: 6. Jun 2007
Ort: Dresden
185 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#11

AW: Anwendungsdesign: Datenbankanwendung, Refresh.

  Alt 17. Feb 2013, 20:47
das ist nicht möglich, teilweise braucht die datenbank solange. oder zB eine 10 jahresauswertung und man weiß auch nie, welche interessanten einschränkungskriterien der nutzer eingibt.

nimm mal das bsp einer aussenstelle via vpn über dsl anbindung an. man kann doch nicht die komplette anwendung umprogrammieren, nur weil ich eine langsame verbindung habe.
Grundsätzlich sollte man die Anwendung, die Abfragen und die Datenbank so bauen, das es eben keine bzw. kaum Wartezeiten gibt.
Wie beschrieben entscheidet das zB der Anwender, bei den Dingen die er abfragt etc. Oder das Netzwerk, wenn es eben mal zB kurz klemmt, da zB übertragung via Richtfunk zwischen den Hallen stattfindet, seit Virtualisierung entscheidet dies manchmal sogar das Cadsystem, wenn es gerade massig daten schreibt und der cluster ausgelastet ist und selbst die einfachsten Dinge sekundenlang brauchen.

Wenn ich nur 1x pro Jahr meine Jahresauswertung fahre, dann benötige ich keine Optimierung (z.B. DWH), aber ansonsten richtet man eben eins ein. Und wenn das immer noch ein Overkill ist, dann werden eben entsprechende redundante Tabellen eingebaut.
Vorhanden. Man weiß aber wiederrum nicht, wie der Anwender es bedient. 5 Sekunden bis "Ihre Anwendung reagiert nicht mehr" ist nicht lang, bei vielen Daten. Wir verwenden für den Anwender zB http://www.devexpress.com/Products/VCL/ExPivotGrid/ für das Customizing. Und auch da gibt es zT das Problem, das es bei (wirklich riesen) Datenmengen beim Umsortieren hängt. (zB hat mir ein Anwender das vor kurzem gezeigt, als er 1 mio Datensätze zum Energieverbrauch seines Glühofens geladen hatte [das wird in einem thread gemacht da hier die Wahrscheinlichkeit für sowas hoch ist] und anschliessend umsortiert bzw. summiert <= Laufzeit länger 5 Sekunden.

Und Paging übers Netz ist ja auch kein Problem. Und DAS ist keine Programmierung extra für eine langsame Verbindung, sondern eine nachhaltige.
Auch hierfür gibt es bei SQL Servern einfache Möglichkeiten, zB CursorFetch usw.
Zusätzliche Layer - solche Techniken kann man sicher verwenden - führt aber natürlich auch sofort zu Geschwindigkeitseinbusen.

Jedoch weiß ich prinzipiell auch hier nicht, wie lange es braucht. Spielt auch keine Rolle, jeder Netzwerktraffic kann mal hängen, egal wieviele Daten.

Das Problem des Abbrechens eine lange dauernden Abfrage bleibt jedoch bestehen.
Das wiederrum ist kein Problem, wenn der Anwender Daten von 1996-heute auswertet, weiß er das dies länger dauert. Mit "Ihre Anwendung reagiert nicht mehr" kann er nichts anfangen. Weiterhin kann man dieses Problem auch serverseitig abfangen, wenn es denn wirklich zu lange dauern sollte und ein Timeout senden. SQL Server bieten auch immer die Möglichkeit eine Abfrage mittels neuem Kommando abzubrechen.

Letztendlich kann ja sogar das Drucken "hängen", wenn der Printserver nicht richtig will. Da alles dies zentral über Klassen gesteuert werden kann, wenn es denn so Designed ist, weiß man die "3" Stellen, wo es dazu kommen kann. Daher könnte man dort eine entsprechende Struktur schaffen - zB ein 2. Thread welcher die Dauer mist und dann zB abbricht. Als Entwickler weiß ich natürlich nie, auf welche Ideen der Anwender kommt und kann somit auch nicht an jeder Stelle ein Multithread modell implementieren.

Hinzu kommt, das manche Unternehmen in der letzten Ecke ein "Pentium 133" stehen haben, der dann plötzlich für Lagerbuchungen wiederentdeckt wurde. Schaut der sich dann die letzten 100 Lagerbewegungen am, dauert es > 5 Sekunden und es kommt "Software geht nicht richtig"

Ich hätte erwartet, man kann zB über eine Nachricht (Postmessage and das BS) mitteilen, das alles iO ist und es noch etwas dauert (mehr als 5 Sekunden).

Aber angenommen man hat alles in Threads, wie verfährt man dann, wenn ich nicht will, das der Anwender etwas machen kann und auch nicht weiß, wie die Anwendung gerade ausschaut (welche Forms offen sind etc). Prinzipiell hätte ich gedacht, man Disabled alle Forms, was aber wiederrum auch nicht "blind" geht, da das unter umständen modale Fensterzustände zerschiesst.

Vereinfachter "WüßtCode" als Bsp:
Delphi-Quellcode:
...
TMyQuery.Refresh;override;

procedure TMyQuery.Refresh;
begin
 ApplicationController.CriticalSection.Enter;//Anwender muß auf Ergebnis warten, kein 2. mal hier hinein.
 ApplicationController.FormManager.DisableAllForms;
 Connection:=ConnectionPool.GetConnection;
  Self.DisableControls;//TDataSet
   T:=TThread.CreateAnonymousThread(
   procedure
    begin
     inherited;
    end);
   T.Start;
  ApplicationController.WaitForThread(T);
  EnableControls;
 ApplicationController.FormManager.EnableAllForms;
 ApplicationController.CriticalSection.Release;
end;
  Mit Zitat antworten Zitat