Re: Union-Abfragen, Geschwindigkeit beim Speichern, Access oder SQL-Server

From: Matthias Krach (mkrach_at_ths-software.de)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 08:02:39 -0800

Hallo "Peter Götz", Du schriebst:

vielen Dank für Deine ausführlichen Antworten, die das Thema Datenbanken
für mich etwas verständlicher gemacht haben.

Die Onlinehilfen zu den Datenbankthemen aufmerksam lesen wird meine
nächste Freizeitbeschäftigung sein.

Vor den Erfolg hat der Herr nunmal den Schweiß gesetzt.

...schnippsel...

> > Wird denn beim Speichern von Datensätzen eine Abfrage in Access
> > auch aktualisiert oder nur die Tabelle? Werden die Datensätze, die
> > von einer Abfrage tangiert werden erst bei Aufruf/Öffnen der
> > Abfrage zusammen gestellt?
>
> Ich weiss nicht so recht, was Du im konkreten Fall mit Abfrage
> meinst? Bei Access kannst Du ähnlich wie beim SQL-Server
> vorgefertigte Abfragen (SQL-Statements) in der Datenbank selbst
> hinterlegen. Über den Namen einer solchen Abfrage kann diese
> ausgeführt werden. Der SQL-Server als aktives System kann selbst
> dieses SQL-Statement aus der DB lesen, es interpretieren und dann
> ausführen. Sprich der SQL-Server wird, nachdem er das zu dieser
> Abfrage gehörende SQL-Statement ausgeführt hat, die daraus
> resultierende Anzahl von Datensätzen zum Client schicken. Eine
> Access.mdb ist kein aktives System, sondern eine simple passive
> Datei. Eine Datei kann von sich aus kein SQL-Statement lesen, es
> interpretieren oder ausführen. Beim Zugriff auf eine Access.mdb über
> die Jet-Engine laufen Dinge die der SQL-Server bei gespeicherten
> Prozeduren macht, innerhalb der Jet-Engine ab. Die Jet-Engine läuft
> aber nicht auf dem Server, sondern eben in jedem einzelnen Client.
>
> Eine in einer Access.mdb gespeicherte Abfrage ist im Grunde nichts
> weiter als ein in dieser *.mdb gespeicherter Text eines
> SQL-Statements. Die Jet-Engine (beim Client) kann dieses
> SQL-Statement aus der DB herauslesen, es interpretieren und dann die
> dazu passende Anzahl von Datensätzen aus der *.mdb herauslesen.
> Sofern dabei passend indizierte Felder zur Verfügung stehen, kann
> die Jet-Engine dabei sehr ökonomisch vorgehen und auch wirklich nur
> die benötigten Datensätze aus der/den Datenbanktabelle(n)
> herauslesen.

Treffer, das war was ich meinte und wissen wollte.
 
> Man liest immer mal wieder Behauptungen, dass die Jet-Engine erst
> den Inhalt der gesamten Tabelle einlesen müsste um dann daraus die
> der im SQL-Statement enthaltenen Where-Klausel entsprechenden
> Datensätze herauszufiltern. Bei halbwegs intelligenter Indizierung
> der richtigen Felder ist das keineswegs so. Die Jet-Engine wird da
> meist gewaltig unterschätzt.

...schnippsel...

> Vorausgesetzt die in der Where-Klausel des auszuführenden
> SQL-Statements sind passend indiziert, dann kann die Jet-Engine ganz
> gezielt und selektiv, nur die tatsächlich benötigten Datensätze aus
> der *.mdb herauspicken und auch wirklich nur diese zum Client hin
> einlesen. Es muss keineswegs die gesamte Tabelle von der *.mdb zum
> Client übertragen werden.

Darf die WHERE-Klausel dafür dann nur indizierte Felder bzw. nur ein
indiziertes Feld enthalten?

> > Hier vermute ich den Unterschied zwischen in Access gespeicherten
> > Abfragen und solchen die ich per SQL in meiner Anwendung habe.
>
> Der Unterschied ist eigentlich gar nicht so gross.
> Beim SQL-Server läuft halt einfach der aktive Teil des DB-Systems,
> also das Programm, welches die SQL-Statements interpretiert und
> ausführt auf dem Server. Die Clients schicken ihre Anforderungen zu
> diesem Programm. Dieses Programm greift dann entsprechend der
> Anforderung auf die eigentliche(n) DB-Datendatei(en) zu, liest die
> angeforderten Daten dort heraus und übergibt sie dem jeweiligen
> Client. Hat ein Client einen Befehl geschickt, der nur Daten ändert
> oder löscht, aber keine Daten zurückerwartet, wird das Programm
> SQL-Server eben genau diesen Befehl ausführen und nach Abschluss
> eben nur den Erfolg oder Misserfolg der Operation zurückmelden.
>
> Die Jet-Engine ist ein mit dem SQL-Server vergleichbares Programm.
> Nur läuft dieses Programm eben nicht auf dem Server, sondern auf dem
> jeweiligen Client. Wenn die Jet-Engine auf Daten in der *.mdb
> zugreifen will, liegen eben diese Daten nicht unbedingt auf dem
> gleichen Rechner, sondern eben irgendwo auf einem Server im LAN oder
> notfalls auch weiter weg. Wenn nun ein Programm, welches auf dem
> Client läuft, Daten aus einer Access.mdb braucht, schickt es die
> entsprechende Anforderung (SQL-Statement) an das ebenfalls auf dem
> Client laufende Programm Jet-Engine. Die Jet-Engine interpretiert
> das SQL-Statement und führt dann (übers LAN) genau die dafür
> erforderlichen Lesezugriffe auf die *.mdb aus. Möchte das
> DB-Programm irgendwelche Datensätze ändern oder löschen, schickt es
> die entsprechenden SQL-Statements an die Jet-Engine, diese
> interpretiert auch das wieder und ändert oder löscht dann eben die
> gewünschten Datensätze.
>
> Im Grunde läuft bei der Jet-Engine beim Zusammenspiel mit einer
> *.mdb das Selbe ab, was beim SQL-Server eben auf dem Server beim
> Zusammenspiel zwischen der DB-Engine des SQL-Servers und den vom
> SQL-Server verwalteten Datendateien abläuft.
>
> Bei der Jet-Engine in Verbindung mit *.mdb ist eben nur der Weg
> zwischen dem aktiven Programm (DB-Engine) und den Datendateien
> länger (sofern die *.mdb nicht auf dem Client liegt).
>
> Dabei ergibt sich natürlich auch noch ein weiterer Effekt.
> Der SQL-Server bekommt Anfragen von Clients und stellt die, wenn er
> gerade keine Zeit hat in einen Zwischenspeicher (Puffer). Dort
> können eine ganz Menge solcher Anfragen in die Warteschlange
> gestellt werden und von dort aus, dann der Reihe nach abgearbeitet
> werden. Dass das Programm SQL-Server gerade was anderes zu tun hat,
> merken die Clients eigentlich nur daran, dass die Antwort auf eine
> gestellt Anfrage möglicherweise etwas länger dauert.
>
> Bei der Jet-Engine, die im Speicher des Clients abläuft, sieht das
> etwas anders aus. Wenn die einen Datensatz lesen oder schreiben
> will, dann kann es passieren, dass gerade eine auf einem anderen
> Client laufende Jet-Engine an der *.mdb etwas ändert. Für die erste
> Jet-Engine bedeutet dies, dass sie erkennt, dass die *.mdb gerade
> anderweitig belegt ist und sie löst deshalb einen Fehler aus. Dieser
> Fehler muss von dem aufrufenden Programm ausgewertet werden. Das
> könnte z.B. so aussehen, dass das aufrufende Programm in diesem Fall
> einige Millisekunden wartet und dann den gerade misslungenen Befehl
> nochmal an die Jet-Engine schickt.
>
> Der Unterschied zum SQL-Server ist also der, dass bei diesem
> eigentlich ein Konfliktfall (mehrere Programme wollen auf die selbe
> Datei zugreifen) gar nicht vorkommen kann, da ja nur ein einziges
> Programm, nämlich die DB-Engine des SQL-Servers direkten Zugriff auf
> die Datendatei(en) der SQL-Server DB hat.
> Bei einer *.mdb gibt es in den meisten Fällen kein zentrales
> Programm, welches nur allein Zugriff auf die darin befindlichen
> Daten hat. Jedes x-beliebige Programm, nicht nur eine Jet-Engine,
> kann auf diese Datei zugreifen. Wird die Datei gerade von einem
> anderen Programm bzw. anderen Client bearbeitet, wird das wie bei
> jeder anderen Datei auch, erkannt und führt zu einem Fehler, der
> dann eben entsprechend behandelt werden muss. Die Fehlerbehandlung
> ist also bei der Zusammenarbeit mit der Jet-Engine ein ganz
> zentraler Punkt und erfordert einen entsprechend hohen
> Programmieraufwand.
>
> > Wie geht hier ein SQL-Server vor? Ist es hier so, daß ich z.B.
> > durch stored prozedures die benötigten Datensätze auf dem Server
> > zusammenstellen lassen und nur das Ergebnis auf den Client
> > übertragen kann?
>
> Ja.
> Das aktive Programm SQL-Server bekommt vom Client den Auftrag
> irgendeine gespeicherte Prozedur auszuführen. Der SQL-Server stellt
> diesen Auftrag in seinen Puffer und wenn er dann irgendwann mal Zeit
> hat, führt er diesen Auftrag aus und liefert genau die daraus
> resultierenden Daten an den jeweiligen Client zurück.
>
> > Der SQL-Server ist doch eine "aktive" Datenbank im Gegensatz zu
> > z.B. Access, die eine passive Datenbank ist. Was sind die
> > Aktivitäten, wo also die Vorteile?
>
> Der Vorteil ist, dass nur ein einziges Programm, nämlich der
> SQL-Server selbst Zugriff auf die eigentlichen Daten hat. Kein
> anderes Programm hat die Erlaubnis, direkt an den Daten etwas zu
> ändern oder diese zu lesen. Jeder Zugriff auf die Daten läuft immer
> erst über das Programm SQL-Server. Dieses Programm stellt die von
> den verschiedenen Clients kommenden Aufträge in einen Puffer und
> arbeitet sie dann von dort der Reihe nach ab. Es kann also gar nicht
> vorkommen, dass zwei Programme oder eben zwei Clients gleichzeitig
> auf die selben Daten zugreifen.

Diese Ausführungen haben mir sehr geholfen, vielen Dank dafür.
 
> > Fachbücher, die darüber etwas aussagen habe ich bisher nicht
> > gefunden.
>
> Zumindest deutschsprachige Bücher wirst Du vermutlich vergeblich
> suchen. Was ich bisher so an deutschsprachigen Büchern zum Thema
> Datenbanken gelesen habe, war nicht wirklich weltbewegend.
>
> > Woher bekomme ich Informatioenn/Literatur, die z.B. Access und SQL-
> > Server gegenüberstellen? Gibt es so etwas überhaupt?
>
> Ich bin nicht sicher ob so etwas wirklich sinnvoll wäre.
> Du musst einfach verstehen, dass ein SQL-Server nicht nur eine
> zentrale Datei ist, in der irgendwelche Daten abgelegt werden,
> sondern dass der SQL-Server auch noch ein Programm beinhaltet,
> welches diese zentrale Datendatei(en) ganz alleine verwaltet.
> Eine Access.mdb dagegen ist kein Programm, sondern eben nur eine
> simple zentrale Datei in der einer oder mehrere Clients ihre Daten
> ablegen können.
>
> Im Prinzip kannst Du Dir natürlich mit einer *.mdb und einem
> Programm, welches auf dem Server läuft einen SQL-Server nachbauen.
> Dieses Programm kann über die Jet-Engine auf eine Access.mdb
> zugreifen. Zur anderen Seite hin, also zum LAN, stellt dieses
> Programm Schnittstellen bereit, über welche die Clients
> Datenanforderungen bzw. Befehle an dieses auf dem Server laufende
> Programm senden und entsprechende Daten zurückerhalten. Die Clients
> bekommen also keinen direkten Zugriff auf die *.mdb mehr, sondern
> müssen dem auf dem Server laufenden Programm, genauso wie dem
> SQL-Server, erst mal sagen, was sie haben wollen. Das zentrale
> Programm geht dann ans Regal (die eigentlichen Daten in der *.mdb)
> sucht das gewünschte heraus und gibt es dann dem anfordernden
> Client.

Auch diese Ausführungen haben mir sehr geholfen, vielen Dank dafür.

> > > Möchte jemand ältere Daten aus so einem Archiv
> > > mal einsehen, schiebt er die entsprechende CD in sein Laufwerk
> > > und öffnet mit dem ganz normalen Programm die auf dieser CD
> > > befindliche *.mdb.
> >
> > Da kann ja keine *.ldb angelegt werden. Klappt das trotzdem oder
> > muß die DB von der CD kopiert werden?
>
> Bei einem Archiv wird man in der Regel nur lesend zugreifen.
> Öffnet man eine *.mdb exklusiv, dann wird keine *.ldb benötigt, da
> durch das exklusive Öffnen der *.mdb von allen anderen evtl.
> zugreifenden Clients sofort erkannt wird, dass die *.mdb momentan
> nicht verfügbar ist. Man öffnet die Archiv-DB also einfach im
> Exclusiv-Modus, liest die gewünschten Daten und schliesst sie
> wieder. Das geht ganz ohne *.ldb.
>
> >
> > Was passiert bei einer Weiterentwicklung der Anwendung? müssen
> > dann die Archivdatenbanken auch upgedatet und neu auf CD gebrannt
> > werden?
>
> Das kommt auf die Art der Weiterentwicklung an, sprich darauf, ob
> und was Du an der Datenstrukur innerhalb der DB änderst. Wenn Du
> grundlegende Änderungen an der Struktur der DB vornimmst, ist es
> egal ob das bei einer *.mdb, bei einem SQL-Server oder einem
> sonstigen DB-System geschieht. Es wird in jedem Fall an irgend einer
> Stelle Programmänderungen erfordern.
>
> > Kannst Du so gewährleisten, daß die Daten auch in 15, 20 Jahren
> > oder sogar 30 Jahren noch einsehbar sind - z.B. bei
> > Betriebssystemwechsel,
>
> Natürlich nicht.
> Aber auch da macht es keinen Unterschied ob die Daten in einer
> SQL-Server DB oder in einer *.mdb gespeichert sind. Die Chance die
> Daten aus einer auf einer CD in einer *.mdb in 20 Jahren noch
> herauszulesen sind eher grösser als bei Daten die in einem
> SQL-Server gespeichert sind.
>
> > Weiterentwicklung der Hardware usw.? Ich kenne alte
> > Clipperprogramme (Dbase), die auf neuer Hardware nicht mehr
> > laufen, weil die Hardware zu schnell ist.
>
> Na ja, das sind aber Dinge, die nun wirklich der Vergangenheit
> angehören. Ein alter SQL-Server 6.5 oder eine ältere Version der
> Jet-Engine laufen auch auf modernen schnellen Rechnern in der Regel
> ohne Probleme.
>
> > Man kann den Kunden ja nicht zumuten, sich irgendwo noch
> > einen Oltimer hinzustellen, nur um evtl. mal alte Daten einsehen zu
> > können. Und auch ein Oltimer geht mal kaputt, was dann?
>
> Das ist auch gar nicht nötig.
> Das Programm, welches die *.mdb von einer CD liest, muss eben auf em
> jeweiligen System laufen. Ob das System nun alt oder neu ist, spielt
> keine Rolle. Auf dem neueren wird es vermutlich schneller laufen.
> Aber dagegen ist ja kaum was einzuwenden. Ansonsten verstehe ich
> nicht so recht, wo Du da ein Problem siehst.
> Wenn irgendwann mal ein xxx-Bit Betriebssystem auf den Markt kommt,
> das zum bisherigen Windowsstandard nicht mehr kompatibel ist, wird
> auf einem solchen Systmem weder ein SQL-Server noch eine Jet-Engine
> mehr laufen. Also ist es so gesehen erst mal völlig egal ob Du mit
> der Jet-Engine oder dem SQL-Server arbeitest.

Die Nachfragen bezüglich der Archivierung bzw. Deiner Antwort, die
Archivdaten auf CD zu brennen, hatte nichts mit meinem Datenbankproblem
zu tun sondern war reine Neugier, wie Du die von mir gesehenen Probleme
einschätzt und evtl. gelöst hast. Trotzdem vieln Dank auch hier für die
Horizonterweiterung.
>
> > Die Tabelle Archiv wird doch von neuen Datensätzen nicht berührt.
> > Für die Archvierung wird es eine eigene Form geben, die die
> > Aufgabe des "verschiebens" der Datensätze Usergesteuert übernimmt
> > - oder was meinst Du mit zwei Tabellen?
>
> Genau das ist eben der Witz bei einem Archiv, welches genau die selbe
> Datenstruktur wie die tagesaktuelle DB hat. Man braucht kein
> zusätzliches Programm oder zusätzliche Forms um damit auf das Archiv
> zuzugreifen. Exakt das selbe Programm mit den selben Forms kann die
> aktuelle *.mdb und eine irgendwo aus dem Panzerschrank geholte CD
> mit einer darauf befindlichen Archiv.mdb lesen.
 
...schnippsel...

> Viel einfacher und effizienter ist es, die gesamte Datenmenge erst
> mal in ein Recordset mit clientseitigem Cursor einzulesen. Die Daten
> liegen nun im Speicher des Clients. Und nun kann man bei ADO per
> Recordset.Sort die Sortierung mit beeindruckender Schnelligkeit
> beliebig ändern, ohne dafür auch nur noch ein einziges mal auf die
> Datenbank zugreifen zu müssen. Und wenn es dem Benutzer einfällt die
> Sortierung seines Recordsets im Sekundentakt zu ändern, dann berührt
> das die Datenbank (*.mdb) überhaupt nicht. Sie erfährt davon noch
> nicht mal was.

Geht das nur bei ADO? Bei DAO habe ich doch auch Recordset.Sort

...schnippsel...

> Schau Dir die Dokumentation zur Jet-Engine, zu ADO und die
> Dokumentation zum SQL-Server gründlich an. Das ist eine Menge Zeug
> zum Lesen. Aber die Mühe musst Du Dir antun, wenn Du wirklich
> verstehen willst, wie und was die verschiedenen DB-Systeme arbeiten.

Das wird meine nächste Freizeitbeschäftigung sein.
 
...schnippsel...

> Gruß aus St.Georgen
> Peter Götz
> www.gssg.de (mit VB-Tips u. Beispielprogrammen)
> 

-- 
MfG
Matthias Krach
aus Plettenberg