Re: Adapter.Fill
- From: "Peter Fleischer" <peter.fleischer_nospam_@xxxxxx>
- Date: Mon, 22 Sep 2008 20:14:53 +0200
"Jan" <Jan@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag news:C4371C61-3B64-437F-8A8F-FC0028A8C6BF@xxxxxxxxxxxxxxxx
Hallo Peter,
stimmt, subquery ist irreführend. Aber was meinst Du mit dem vorangestellten
Semikolon? Wenn es sich um einen Anweisungsstapel handelt muß die
vorhergehende Anweisung mit einem Semilkolon enden?
Wenn eine CTE-Anweisung vom Client bereitgestellt wird, dann muss am Anfang ein Semikolon stehen.
Mit DB-Server = Client = Webserver meine ich die einfach Situation, das auf
einem Rechner, der ein Webserver ist, neben der Webserversoftware auch die
DB-Server-Software läuft und die Anwendung, die auf dem Webserver läuft, ist
der Client des DB-Servers.
Was soll denn das für eine Client-Anwendung sein - eine Terminal-Server-Anwendung oder ein Dienst?
Ressourcenschonend bedeutet in unserem Fall, das ich nach der Variante
suche, die auch unter erhöhter Last, sprich viele Besucher rufen gleichzeitig
die Seite auf, zuverlässig arbeitet und nicht abschnmiert, weil die
Anwendung viel zuviel Ressourcen gleich welcher Art beansprucht.
Also doch kein Terminalserver? Eine Webserver-Anwendung?
Die (in ASP.NET) gegebenen Lösungen lesen offenbar immer die kompletten
Daten aus der DB, um dann nur die wenigen Datensätze, die auf einer Seite
Platz finden, anzuzeigen.
Warum meinst du, dass das so ist?
Wenn ich hundertausende Seitenaufrufe im Monat habe und zehntausend
Datensätze in der DB, dann finde ich das - wie oben schon erwähnt - irgendwie
beunruhigend und suche natürlich nach Wegen, das so zu optimieren, das die
Belastung des (physikalischen) Webservers pro Seitenaufruf so gering wie
möglich ist, damit er zuverlässig arbeitet.
Irgendjemand muss doch die gewünschten Seiten raussuchen. Wenn du Angst um die Performance hast, dann puffere die vollständige Abfrage nachts und greife am Tage immer auf den Puffer der letzten Nacht zu. Bei Abfragen zu Banken bekommst du auch in vielen Fällen auch nur den Stand des Vortages.
Ich glaube, das wir mit Deiner Anregung, CTEs einzusetzen, eine gute Lösung
haben. Die Selektierung und Entscheidung, welche Datensätze auf die Seite
kommen, läuft innerhalb der Datenbank ab und nur die tatsächlich benötigte
Datenmenge wird ausgegeben. Einziger Kritikpunkt ist die Sortierung, die bei
einer Lösung mit "Fill und Abfrage-Abbruch" entfallen könnte. Dafür kann ich
aber die Daten dann mit einem einfachen DataReader ausgeben.
Wie willst du ohne Sortierung sichern, dass du ohne Cache (vollständig alle datensätze puffern) immer nur wirklich die nächsten Datensätze bekommst. Ohne Sortierung ist das ein Lotteriespiel, da der Server zufällig irgendwelche Sektoren, Cluster, Seiten o.ä. bereitstellt.
Blöd finde ich aber nach wie vor, das ich, nur um die Gesamtmenge der Seiten
zu berechnen, für jeden Seitenaufruf zusätzich ein SELECT COUNT fahren muß,
Wenn du ins Kino gehst, weist du auch bei der ersten Szene, wie lange der Film dauert? Ohne Zusatzinformation (vorherige Information durch den Kinobetreiber) kannst du nicht die Dauer der Vorstellung wissen.
aber das läßt sich wohl nicht vermeiden und wird den DB-Server auch nicht
wirklich nenenswert belasten, oder?
Ein SELECT Count... ist nin wirklich keine Belastung für den Server im vergleich zu beispielsweise JOIN.
--
Viele Gruesse
Peter
.
- Follow-Ups:
- Re: Adapter.Fill
- From: Jan
- Re: Adapter.Fill
- References:
- Adapter.Fill
- From: Jan
- Re: Adapter.Fill
- From: Peter Fleischer
- Re: Adapter.Fill
- From: Jan
- Re: Adapter.Fill
- From: Peter Fleischer
- Re: Adapter.Fill
- From: Jan
- Re: Adapter.Fill
- From: Peter Fleischer
- Re: Adapter.Fill
- From: Jan
- Re: Adapter.Fill
- From: Peter Fleischer
- Re: Adapter.Fill
- From: Jan
- Adapter.Fill
- Prev by Date: Re: ADO.NET- Performanz beim Schreiben vieler neuer Datensätze
- Next by Date: Re: DataTable über DataAdapter speichern
- Previous by thread: Re: Adapter.Fill
- Next by thread: Re: Adapter.Fill
- Index(es):
Relevant Pages
|