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

[sancho1980]

hmm
ich weiß nicht ob ich das richtig verstanden hab
ich hab mich auch mal im netz umgeschaut
also so wie ich das verstehe, sorgt ein clustered index dafür, dass die wahrscheinlichkeit relativ hoch ist, dass zwei aufeinanderfolgende einträge auch auf derselben seite stehen
das bringt mich zu zwei fragen:
1) wie soll das gehen; schließlich habe teilweise ja mehrere indizes für die selbe tabelle, je nachdem nach welchem feld ich grade sortieren will
2) wie muss ich mir diese datenbankseiten eigentlich vorstellen? am ende landet es doch alles auf der platte...

danke,

martin

[marabu]

Zitat:

Zitat von sancho1980

also so wie ich das verstehe, sorgt ein clustered index dafür, dass die wahrscheinlichkeit relativ hoch ist, dass zwei aufeinanderfolgende einträge auch auf derselben seite stehen

Korrekt.

Zitat:

Zitat von sancho1980

wie soll das gehen - schließlich habe teilweise ja mehrere indizes für die selbe tabelle, je nachdem nach welchem feld ich grade sortieren will

es ist nur ein einziger clustered index pro table resp. view möglich. Die tupel werden in den Index eingebaut, die leaf nodes enthalten keine pointer mehr, sondern direkt die Daten.

Zitat:

Zitat von sancho1980

wie muss ich mir diese datenbankseiten eigentlich vorstellen? am ende landet es doch alles auf der platte...

Der verwaltete file space wird gekachelt, die dadurch entstehenden pages sind physische Verwaltungsobjekte. Muss einen aber nur in high performance Anwendungen interessieren.

marabu

[sancho1980]

hmm ich glaub das hab ich verstanden
ist es jetz so, dass der primärindex automatisch ein clustered index ist?
oder muss ich das noch irgendwie explizit sagen, also etwa wie 'create clustered index x ..'

[marabu]

Einen CLUSTERD INDEX musst du explizit erzeugen - und in den seltensten Fällen ist der PK der geeignete Kandidat. Der PK ist sehr oft ein surrogate key - besser geeignet ist da ein Sortierschlüssel (z.B. PLZ).

Übrigens: es ist eine gute Idee zuerst den clustered index zu erzeugen, da durch die Reorganisation der Daten alle anderen Indexe ungültig werden und neu aufgebaut werden müssen.

marabu

[sancho1980]

wie erzeug ich so einen clustered index?
bei "create clusterd index" bekomm ich eine "invalid token"-meldung

[mkinzler]

Ichglaube nicht das InterBase clustered Inidices unterstützt. Das ist m:W. ein Feature Des MSSQL.