workaround dbgrid in client-server-anwendung

[sancho1980]

Hallo
ich weiß, eigentlich *soll* man das DBgrid bei client/server-datenbanken wegen des hohen datentransfers nicht verwenden, aber ich hab mir einen workaround überlegt, von dem ich aber leider nicht so richtig weiß, wie ichs praktisch umsetzen soll. die idee is folgende:

es werden einfach immer nur soviele datensätze an den client geschickt, wie zu einem bestimmten zeitpunkt auch grad im dbgrid dargestellt werden können. dazu müsste man (1. Problem):

1) irgendwie über den code herausbekommen, wieviele datensätze momentan im dbgrid dargestellt werden können. eine entsprechende funktion oder eigenschaft hab ich leider nicht ausfindig machen können; vielleicht gehts auch gar nicht...zur not könnte man ja pauschal so 50 datensätze rüberholen; das tut bestimmt nicht weh...oder hat jemand eine elegantere lösung

das zweite problem hängt damit zusammen, dass ich in sql nicht so wirklich fit bin..sobald der user sich über den letzten oder ersten datensatz hinausbewegen will, müsste man einen select-query abschicken, der eben auch wieder nur so 50 datensätze holt und zwar ab dem letzten vorhandenen datensatz aufwärts; wenn ich bsp-weise 100 datensätze hab, mit ID 1 - 100 und sich in meinem datenset gerade die datensätze 1-50 befinden und der user sich grad auf datensatz 50 bewegt, müsste der sql-befehl etwa so aussehen

[pseudo-sql]select * from die nächsten 50 datensätze
where id > :ID_letzterVorhandener[/pseudo-sql]

wie muss ich das richtig schreiben?

sehr dankend,
martin

[mkinzler]

Zitat:

1) irgendwie über den code herausbekommen, wieviele datensätze momentan im dbgrid dargestellt werden können. eine entsprechende funktion oder eigenschaft hab ich leider nicht ausfindig machen können; vielleicht gehts auch gar nicht...zur not könnte man ja pauschal so 50 datensätze rüberholen; das tut bestimmt nicht weh...oder hat jemand eine elegantere lösung

Über die Größe des Grids mit Verbindung mit der Schriftgröße, könnte man das berechnen.

zu 2.) Ich würde das nicht an der ID festmachen. Diverse DBMS bieten mit LIMIT-die Möglichkeit die Ergebnismenge zu begrenzen/ mit Offset zu arbeiten.

[sancho1980]

stimmt, dass mit der größe und schriftgröße ist ne gute idee...

was den sql-query anbelangt, kannst du mir bitte mal ein beispiel geben, wie das syntaktisch in etwa aussehen müsste?

danke,

martin

[Hansa]

DBGrid1.ScrollBy nicht gesehen ?

[mkinzler]

Schau mal nach ROWS in der IB Anleietung.
In FB würde es

SQL-Code:

select * from tabelle first 50 skip 50;

um die zweiten 50 Zeilen anzuzeigen, mysql

SQL-Code:

select * from tabellel imit 50,50;

[sancho1980]

hmmm...
hab mal bisschen gegooglet und nebenbei n bisschen ausprobiert in isql; folgendes klappt prima:

SQL-Code:

select * from dicentries where id > 280 rows 50;

das gibt mir die ersten 50 records deren id größer als 280 ist

leider weiß ich nicht wie es andersrum geht, das brauch ich ja auch noch, also beispielsweise:

SQL-Code:

select * from dicentries where id < 280 last rows 50;

- > klappt leider nicht

(die letzten 50 einträge, deren id kleiner als 280 ist (229-279)

[sancho1980]

falls es wen interessiert, ich habs raus

SQL-Code:

select * from dicentries where id < 350 order by id descending rows 5;

die letzten 5 datensätze für die gilt id < 350...

[alzaimar]

Nur mal so: Dein 'demand fetching', also Zugriff nach Anforderung ist schon die richtige Lösung, nur hast Du prinzipiell immer noch ein Problem: Wenn jetzt 100 Nutzer gleichzeitig durch eine Tabelle scrollen, ergibt das dann doch massig Rechnerei in der Datenbank sowie Netzwerktraffic. Ob das dann die richtige Lösung ist, sei dahingestellt.

Weiterhin muss die gesamte Tabelle ja nach der ID sortiert werden und DANN erst können die nächsten Zeilen für die Anzeige übermittelt werden. Das ist nur dann ohne zusätzlichen echten Sortieraufwand auf der Datenbankseite möglich, wenn die Datensätze ohnehin nach ID sortiert auf der Platte liegen. Ich kenn FB nicht, aber bei MSSQL heißt das Zauberwort 'Clustered Index'. Soetwas gibt es bestimmt auch für Firebird und Du hast bestimmt auch daran gedacht, ich wollt's nur mal anmerken: Dieser Clustered Index (einen pro Tabelle) sorgt nämlich dafür, das die Records genau so sortiert sind und dann wird ein 'ORDER BY ID' (Clustered Index auf ID) vom Optimizer wegoptimiert.

[sancho1980]

ich weiß nicht ob ich das jetz alles richtig verstanden hab
ich hab natürlich einen unique index für das feld id in meiner db; ist das so ein clustered index, oder ist das nochmal was anderes?
wenn ich jetz 'order by id' verlange, sollte doch dieser index automatisch genutzt werden womit das doch eben keine rechnerei verursachen sollte, oder?
bin noch ziemlich neu bei delphi und interbase, bin also für verbesserungen sehr dankbar, da ich momentan ein terminologieverwaltungssystem als teil meiner diplomarbeit neu schreibe (aber nicht als informatuker sondern als dolmetscher, womit ich mich für teils mangelnde fachkenntnis entschuldigen will *g)
sers
martin

[marabu]

Hallo Martin,

das relationale Datenmodell nach Codd verlangt, dass jede Ordnung über ein tupel set per ORDER BY Klausel herzustellen ist. Um Abfragen zu beschleunigen lässt sich der Hersteller eines RDBMS natürlich etwas einfallen. Bei einem "normalen" Index wird die Ordnung wenn möglich über ein sortieren der Index-Einträge hergestellt. Mit dem "clustered" index hat MS die Möglichkeit geschaffen, dass die Daten einer Tabelle index-sequentiell ausgelesen werden können, wobei der Index bereits in sortierter Form gespeichert wird. Das erlaubt dem Query Optimizer die ORDER BY Klausel bei der Planerstellung einfach zu eliminieren.

Freundliche Grüße vom marabu