Post by Holger VorbergEin Umstellung auf eine andere
Datenbank könnten wir mit einer einfachen Änderung eines ODBC Connection
Strings, der sich in einer .INI Datei befindet, erledigen.
Mere Mortals läßt ja auch sowas in der Art zu, nimmt aber,
solange man auf VFP-Daten zugreifen möchte immer noch
lokale Views, die im Namen alle mit lv_beginnen und wenn
man auf Remotezugriff umschaltet werden Views mit rv_
genommen.
Wenn Du wirklich dieselben Remoteviews für die VFP-
als auch die Remotedatenbank (meist ja wohl MS SQL-Server)
nimmst, schränkst Du Dich im SQL ja schon etwas ein,
richtig? So werden z.B. gegenseitig nicht alle Feldtypen
unterstützt und das auf beiden Datenbanken funktionierende
SQL muß das berücksichtigen.
Einerseits macht das den Umstieg dann wirklich einfach,
aber auch nur, wenn man schon im voraus weiß, wo's hin-
gehen soll. Je mehr Datenbanken man damit unterstützen
will je mehr schränkt man sich damit doch ein. Und ehrlich
gesagt schmeckt mir diese mehr oder minder große Lüge
der leichten Datenbankmigration nicht.
Ich hab's im Laufe der Zeit in mehreren (Lern)stufen errreicht,
daß die VFP-Datenbank in ihrer Performance trotz massiv
steigender Datenmenge und leicht steigender Userzahl besser
wurde, so daß sich die Befürchtung, die Performance reicht
irgendwann nicht mehr nie bestätigt hatte.
Gerade was ODBC angeht hattest Du außerdem ja schon
selbst mal gesagt, damit setzt man auf einen aussterbenden
Ast. Totgesagte leben zwar immer länger, aber Cursoradap-
toren zu nutzen wäre dann ja schon der zukunftsträchtigere
Schritt. Das sollte man auch berücksichtigen. Ich muß dazu
sagen, daß ich keinerlei Erfahrungen mit Cursoradaptoren
gemacht habe, man las in der Anfangszeit von VFP8 oft-
mals Fragen sehr grundsätzlicher Art "Wie geht das überhaupt?"
"Hat jemand mal ein Beispiel?" und nach einer Zeit kam das
Thema gar nicht mehr. Insofern landet man dann evtl. doch
wieder bei Views, purem SQL bzw. xBase-Code a la
Scan..Endscan, Scatter, Gather. Und um mal Christof Wol-
lenhaupts Geschmack zu erwähnen: Gerade letztens ver-
schmähte er wieder Views und lobte für SQL-Server anbin-
dung SQL-Passthrough aus. Mag ein wenig Geschmacks-
sache sein, aber Views haben schon so ihre Kinken.
Um zur Frage nach "Blättern in den Daten" zurückzukommen:
a) Ohne View: Tabelle komplett anbinden ist natürlich zunächst
mal "schön schnell". Es stellt sich aber trotzdem schnell das
Problem ein, daß man doch lieber nur einen nach mehreren
frei wählbaren Kriterien eingeschränken Ausschnitt der Daten
sehen möchte, was mit SET FILTER TO nur bedingt mach-
bar ist. Der Ansatz führt häufig auch zu einem sich leicht
rächenden unnormalisierten Tabellendesign, selbst wenn
man mit SET RELATION TO arbeitet, um passende Child-
daten anzuzeigen.
b) Mit Views: Da man hier mit Viewparametern und JOINS
arbeitet hat man die gewünschte Ansicht im gewünschten
Ausschnitt, natürlich aber zum Preis, das die Daten zunächst
mal beschafft werden müssen. Das ist dabei auch gar nicht
mal der Punkt, denn so oder so muß das, was auf den Clients
angezeigt wird durchs Netzwerk kommen. Alleine aber schon
die Stabilität der Dateien spricht für Views, SQL-Abfragen und
derlei und gegen direkte Tabellenanbindung.
Da man beim Selektieren der Daten - wie auch immer - in Anzeige-
cursoren aber die Wartezeit auf das Gesamtergebnis hat kommt
man schnell auf die Idee, die Wartezeit ähnlich der Tabellenanbindung
zu drücken, indem man eben die Daten nur Seitenweise holt, also z.B.
nur die ersten 10-20 Ergebnisdatensätze auf "Seite 1", für "Seite 2"
dann die nächsten 10-20 etc. Und genau das stellt sich per Views auf
VFP-Daten bzw. SQL als nicht machbar heraus, es gibt hier nur TOP,
womit man die ersten Datensätze holen könnte und bei umgekehrter
Sortierung die letzten, aber nie die Mitte eines Ergebnisses, ohne
es vorher nicht vollständig zu heben. Da hilft es sehr eine Serverdaten-
bank zu haben, die ein Ergebnis Stückweise liefern kann.
Seitenweise Navigation ist das übliche bei Webanwendung, nicht
jedoch bei Desktopanwendungen. Da bietet sich eher die Strate-
gie an eine Vorabfilterung anzubieten, die Defaultmäßig z.B. auf
Daten des aktuell angemeldeten Users oder der letzten 6 Monate
einschränkt.
Wenn Du unbedingt seitenweise Navigation möchtest, böte es
sich z.B. an den Schritt zu einem Applikationsserver zu gehen,
der die Applikationslogik als Zwischenstelle zwischen Datenbank
und Applikationsfrontend bildet und dabei wirklich Datenbank-
bzw. Fileservernah läuft und so quasi eine Foxprodatenbank
ganz oder teilweise zur Serverdatenbank machen kann, je nachdem
ob das Applikationsfronten nach wie vor auch am Applikationsserver
vorbei auf die/einige Datenbankfiles zugreifen kann oder nicht.
Tschüß, Olaf.