Bei der Datenintegrit�t bin ich ganz Deiner Meinung!
Zur Sortierung!
Haste mal versucht ein Order By in einer SQL Stored Procedure dynamisch
zu setzen?
Als Beispiel:
CREATE PROC USERLISTE
@Sort AS VARCHAR(100)
AS
SELECT Name, Vorname FROM User ORDER BY @Sort
Leider geht das ebend nicht!
Ausweg:
Beispiel:
CREATE PROC USERLISTE
@order AS nvarchar(50)
AS
SELECT *
FROM dbo.KB_objects
ORDER BY CASE @order WHEN 'Name' THEN Name ELSE
NULL END,
CASE @order WHEN 'Vorname' THEN Vorname
ELSE NULL END DESC,
CASE @order WHEN 'label' THEN label ELSE
NULL END DESC,
Usw.
Wie Du siehst geht das �ber Diesen Umweg! Wenn Du aber jetzt auch noch
anfangen willst - Zeilen Kombiniert zu sortieren dann wird das noch
aufwendiger!
Da ist es doch wesentlich einfacher die Daten gleich im DataSet (�ber
DataView) zu sortieren - zumal Du dann immer nur einen Select Anweisung
brauchst!
Weil - einfache Select Anweisung funktionieren auf dem SQLServer, auf
MySQL, auf Access, auf Oracle usw. immer gleich!
Und da dann auch der DataView gleich ist - sinkt der
Implementierungsaufwand auch! Sicher sind Stored Procs. Schneller als
einfache SQL Anweisungen - aber dann mu� man abw�gen - was einem
wichtiger ist!
Was ich haupts�chlich meinte ist das man per DataSet oder wie auch immer
die DB eigentlich nur einmal abfragen mu� - und dann kann der User die
n�chsten Tausend Sortierungen direkt auf den 1x gelieferten Daten
ausf�hren!
Ob man das will - kommt haupts�chlich auf die Daten und Ihre Fluktuation
an - quasi wie h�ufig �ndern sie sich - und sind die �nderungen so
relevant - das ich sie sofort sehen will - oder reicht es mir wenn ich
aller x Min / x Tage frische Daten habe! Eine Sitestatistik reicht ja
quasi wenn Sie jeden Tag bzw. jeden Monat aktualisiert wird! Ein
B�rsenticker sollte die �nderungen dagegen sofort zeigen!
-----Urspr�ngliche Nachricht-----
Von: Joachim van de Bruck [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 10. November 2003 09:22
An: [EMAIL PROTECTED]
Betreff: AW: [Asp.net] Schlaufe statt dataGrid
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
_______________________________________________
Asp.net mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/asp.net
