Hallo! > > Ein paar Gedanken zu "LIMIT 10, 50" ... > > > > Ich gebe zu, dass man mit diesem Befehl ein Paging sehr einfach > > realisieren kann, aber g�be es den Befehl in Transact-SQL, > > ich w�rde ihn > > nicht verwenden und auch meinen Mitarbeitern verbieten, den Befehl zu > > benutzen. > > > > Wenn man eine statische Tabelle hat, die nach einem eindeutigen Index > > sortiert ist, liefert der Befehl auch immer eindeutige Werte. Sobald > > aber eine Tabelle entweder laufend ver�ndert wird (INSERT, DELETE, > > UPDATE von Index-Feldern) oder nicht nach einem eindeutigen Index > > sortiert ist, bekommt man mit "LIMIT 10, 50" auch keine eindeutigen > > Ergebnisse mehr. Bei "unkontrolliert" angewendetem "LIMIT 10, > > 50" ist es > > nicht unwahrscheinlich, dass die �bersprungenen Datens�tze > > auch gelesen > > werden m�ssen. > > Wieso bekommt man bei Tabellen, die sich laufend ver�ndern kein > eindeutiges Ergebnis mehr? > Das ist doch sowas wie: > Select top 10 * from tabelle where id>=50 > Oder? Und das ist doch auch eindeutig....
Sag ich doch (oder meinte ich zumindest) - die Sortierung muss eindeutig sein oder TOP 10 muss bei identischen Schl�sseln auch mehr als 10 Datens�tze liefern. Deine L�sung finde ich korrekt. "LIMIT 10, 50" liefert �hnlich wie bei "SET RECORDCOUNT = 10" mitunter willk�rliche Ergebnisse. Deshalb ist "WITH TIES" beim SQL-Server auch Standard in Verbindung mit "TOP X". > > Mit "TOP 10" in Verbindung mit z. B. "WHERE Index-Feld > ..." hat man > > immer eine performante L�sung. Deshalb sollte m. E. ein > > Datenbankprogrammierer auch auf "LIMIT 10, 50" verzichten. > > > > Um eine Tabelle �ber mehrere Seiten auszugeben, verwende ich "TOP 10 + > > X" und zus�tzlich "WHERE ..." in Verbindung mit einem eindeutigen > > Schl�ssel. Ich lese also z. B. 13 Datens�tze ein und breche > > die Ausgabe > > bei 10 ab, es sei denn, dass mit dem 13. Datensatz das Dateiende > > erreicht wird. So erreiche ich immer alle Datens�tze (auch bei > > Ver�nderungen) und zus�tzlich verhindere ich, dass weniger als 3 > > Datens�tze auf einer Seite stehen. > > Wie meinst Du "So erreiche ich immer alle Datens�tze (auch bei > Ver�nderungen)"? > Wieso erreicht man diee sonst nicht? Zum Beispiel: Ein Benutzer bl�ttert zun�chst eine Seite vor und dann eine Seite zur�ck. Wird dazwischen ein Datensatz eingef�gt, der auf der ersten Seite platziert ist, fehlt im einer auf dieser Seite, den er dann nur durch nochmaliges R�ckw�rtsbl�ttern erreicht. Wetten, dass er das �bersieht? Das ist kein Problem der Datenlogik, sondern der Benutzerf�hrung. Auch �rgert es mich, wenn eine Seite nur einen Datensatz enth�lt. Mein Algorithmus ist da m. E. benutzungsfreundlicher (z. B. in der Regel 15, mitunter bis zu 20 Datens�tze, aber mindestens 5 - durch "TOP 15 + 5") Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
