Hallo! > ... f�r Selektionen/Sortierungen ist m. E. in erster Linie > die Datenbank > und nicht das DataSet zust�ndig. > > -> Sehe ich momentan eigentlich nicht mehr so - denn die > Datenbank wird > mehr und mehr in den Hintergrund treten - und nur noch daf�r da sein - > wof�r sie eigentlich mal geschaffen wurde - n�mlich um Daten zu > speichern! Zu Zeiten der Objektorientierung ist man deutlich besser > bedient wenn man vor allem die Sortierungen �ber ASP.NET > macht - und net > �ber die DB! Das war aber auch schon zu ASP so - wenn man vor allem > Variable Recordsets sortieren wollte - denn dort wurde es vor > allem mit > dem SQL Server und Stored Procedures schwierig!
Hm, interessanter Ansatz ... Ich sehe eher, dass die Datenbank immer mehr in den Vordergrund tritt. Das ist vor allem dann erforderlich, wenn man mehrere Applikationen hat, die auf die Daten zugreifen, und wobei die Datenbank alleine - und nicht jede einzelne Applikation - f�r die Integrit�t der Daten sorgen muss. Es geht also gar nicht in erster Linie darum, ob ein TableScan oder eine Sortierung im Speicher schneller ist, als in der Datenbank. Das d�rfte sich inzwischen herumgesprochen haben, dass man bei den schnellen Rechnern heute nur dann Indizes in der Datenbank braucht, wenn die Datenmenge ziemlich gro� ist oder st�ndig zwischen unterschiedlichen Sortierungen gewechselt werden muss. Das zus�tzliche Lesen einer Indextabelle kann kann mehr Zeit/Speicher beanspruchen als eine Sortierung im Speicher. Beim SQL-Server wird man auch gerade bei komplexen Abfragen die Erfahrung machen, dass die Datenbank f�r die Selektion/Sortierung weniger als eine Sekunde und f�r die Bereitstellung/�bertragung der Daten dann 10 und mehr Sekunden ben�tigt. Es gilt also immer, dass man so wenig Daten wie m�glich aus der Datenbank zieht. In ein DataSet geh�ren also nach wie vor nur die Daten, die man aktuell ben�tigt, also in der Regel etwa eine Bildschirmseite. Die Selektion ist dabei ganz sicher Aufgabe der Datenbank - Indizes braucht man in erster Linie f�r die WHERE-Klausel - und die Sortierung der (wenigen) selektierten Daten kann dann aber wirklich sinnvoll im DataSet erfolgen, vor allem gerade dann, wenn der Anwender noch unterschiedliche Sortierkriterien w�hlen kann. Um Daten nur zu speichern, braucht's jedoch keine Datenbank. Das kann man auch mit beliebigen Dateien, mit Textdateien, mit XML-Dateien, o. a. Die Datenbank ist in erster Linie f�r die Integrit�t und Sicherheit der Daten da und zwar immer dann, wenn mehrere Anwender und besonders mit unterschiedlichen Programmen die Daten nutzen. Erst in zweiter Linie hilft die Datenbank, auch mit gro�en Datenmengen zurechtzukommen. Die Frage ist also nicht "Datenbank oder DataSet?" sondern eher, wie beide Komponenten optimal zusammenarbeiten. Und deshalb hast Du m. E. auch Recht, wenn Du sagst, dass es h�ufig sinnvoll ist, die Daten erst im DataSet zu sortieren. Allerdings wei� ich beim besten Willen nicht, warum es in im SQL Server schwierig sein soll, variable Datensatzmengen zu sortieren (RecordSets gehen auf ADO zur�ck, oder?), selbst variable Sortierkriterien sind doch mit Stored Procedures kein gro�es Problem, oder? Freundliche Gr��e Joachim van de Bruck _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net
