Die Cache Mechanismen vom
MSSQL basieren wie bei vielen Datenbanken auf serverseitiges Caching und auch clientseitiges Caching.
Wer auf Basis von Firebird und seiner Datasource/Dataset Konstruktion das Netzwerkprotokoll durchschaut, wird feststellen, das die Implementation
der meisten Komponenten in Zusammenarbeit mit dem Firebird Client bei jeder dataset.insert/edit/dataset.post und auch bei first, prior, next, last
alle Nachschlagewerte von allen Lookup Datasets ohne Sinn und Verstand nachlädt. Wenn da in einem Lookup halt 10000 Auswahlmöglichkeiten stehen,
werden die so wie vom Programmierer (auch bei Unkenntnis) befohlen komplett nachgeladen.
Ich weiss das einige Clientlib DLLs da mehr oder weniger intelliger den kram lokal cachen und gar nicht erst übers
Netzwerk holen, weil der Server auf Protokollebene sacht, am Result zum vorhin geholt und prepared
SQL hat sich nix
geändert, also nimm den gleich kram noch mal, den der Server vorhin gesendet hab und den die Client
DLL eh ncoh im
Ram
gecached hat . Ob das nun sinnvoll ist bei sehr dynamischen Datenmenge, lass ich mal im Raume stehen, aber
Fakt ist, die Ursache des Unsinns liegt ganz wo anders: Die komplette master/details datasource Implementation ist
kompletter Müll ist. Und daraus könnt Ihr auch schon mal den Rückschluss ziehen, das es keineswegs damit von mir
gemeint ist, das Delphi Applikationen generell scheisse sind, keineswegs, es kommt darauf an, was man wie damit
macht.
Wenn du lookup controls durch edits und buttons ersetzt und bei bedarf den einen Wert, der da angezeigt werden soll, bereits
gejoint vom Server holst und anzeigst, dann muss der gar nichts nachladen.
Wenn der Anwender aber die Auswahl sehen will und den Button klickt, dann kannst du für genau diese Datenmenge immer
noch alles in einem extra
SQL holen, was du anbieten möchtest. Und wenn das wie eine Non
DB Listbox direkt unter dem
Edit eingeblendet wird, die das Result des Nachschalge
SQL auflistet, den Fokus hat und bei Return oder Doppelklick
den Update auf dem Hauptdatensatz macht, so das dessen FK dem gewählten Entspricht und du alle nur für den aktuellen
Datensatz refresht, dann werden aus ein paar hunderttausend übertragenen Datensätzen eben nur einer. Und es hindert
dich keiner daran, alle Inhalte dieser Listbox für dieses Feld auch beim nächsten Auswählen ohne neues Nachladen von der
DB in der jetzt unsichtbaren,aber immer noch instanziierten Listbox vorzuhalten.
Auch wenn viele Delphi Programmierer glauben, das der dblookup kram das so machen würde, NEIN, macht der nicht. Einfach mal Netzwerksniffer
dazwischen packen und dann sieht man was im Endeffekt über den Draht geht. Und wer da gerade Spaß dran hat: Einfach mal im Grid ein Datensatz
der Hauptdatenmenge editieren und dann auf den vorherigen Datensatz gehen (also prior oder cursor up).
Sorgt bei fast allen Grid-Masken dafür, das noch mal der gesamte Klumpatsch im Grid komplett neu gelesen wird, aber erst
mal alle Datensätze bis eof, um dann beim First wieder anzufangen, um den aktuellen zu finden. Und die passenden Lookup
datasets und dblookup fields werden dabei feundlicherweise auch noch mal für jeden navigationsvorgang noch mal komplett
neu nachgeladen. Nur damit Ihr eine grobe Vorstellung davon habt, warum die Performance eurer Anwendung scheisse ist...
Einige Komponenten wie die von devart sind da bei korrekter Benutzung nicht ganz so scheisse, aber die Realität im
Netzwerk zeigt bei meinen Consulting Jobs, das man zwar meint das es nicht so wäre, aber es ist trotzdem oft so wie ich sage.
dblookup datasets zu ersetzen ist auch im Rahmen von evolution einer Software kein Hexenwerk und dblookup controls dann
zu ersetzen ebenfalls nicht. Wenn man aber keine Ahnung hat, was die für einen Scheiss da veranstalten, warum sollte
man da suchen ....
Wenn eben Performance generell scheissegal ist, dann nimmt man eben datasource/dataset mit ohne ende dblookups auf 20 seiten pagecontrol
Dann aber am besten gar nicht erst auf die Idee kommen, mit so einer Anwendung irgendwann mal größere Kunden zu beglücken. Das wird
scheitern, auch bei ganz doller Hardware ....
Wenn die eigentlich erforderlichen Daten durch den lokalen data cache der treiber im
ram gehalten wird und nicht komplett nachgeladen wird,
dann mag es so aussehen, als ob die Plattformen 4-10 mal schneller sind, das bezieht sich dann aber nur auf eure Software und eure Implementation
bzgl: eigene erkenntisse: wer firebird benutzt kann ja mal das tool runterladen
https://ibexpert.com/tcp/tcpipe.zip
dann folgendes einstellen und starten
Statusseite:
Remarks=
fb
BindIp=127.0.0.1
ListenPort=3051
MapIp=127.0.0.1
MapPort=3050
Map=true
Logging=true
LogDataMode=5
Loggingseite:
LogToScreen=true
ScreenLogLines=50000
und danach eure app mal mit connectionstring 127.0.0.1/3051:aliasoderpfadzurdb statt 127.0.0.1/3050:aliasoderpfadzurdb starten.
Dann steht ihr in fb25 unverschlüsselt, was da bei ganz simplen Operationen über den Draht geht und ich garantier jedem dataset/datasource/lookup kram
benutzer, das ihr da auf der logging seite dinge sehen werdet, die auf keine screen eurer applikation sichtbar sind (weil die nur in lookup optionen
sind, die aber nicht geöffnet sind) und die dann eben bei jedem navigieren der Hauptdatenmenge neu nachgeladen werden. Außerdem zeigt euch das Tool
noch an, wie viele Pakete und Bytes da hin und her gejagt wurden.
Das tool bekommt jeder Teilnehmer bei entsprechenden Schulungen von uns, es gibt auch zig millionen andere ähnliche Tools die das alles noch viel besser
können, bringt aber nix wenn man von 10 möglichen besseren Tools auch noch keines benutzt hat oder deren Ausgabe nicht versteht. Wenn ihr wollt könnt
ihr damit auch andere tcpip protokolle umbiegen und darüber sehen, was auch da über den Draht geht. ist zB auch insbesondere beim verstehen, warum https
besser ist als http nicht ganz uninteressant.
Bei fb3 müsste ihr ggf vorher noch den parameter wirecrypt in der firebird.conf anpassen, sonst werdet ihr da nichts lesenswertes sehen.