Hallo! > > > Nicht mehr f�r die t�glich Arbeit braucht, die man aber archivieren > > > m�chte... > > > Alte Projekt-Entw�rfe z.B. wirfst Du ja auch nicht weg, nur weil Du > > sie > > > im Moment nicht mehr nutzt... > > > > Klar schmei� ich das (meiste) weg, ich mach doch heute vieles > > anders als > > noch vor wenigen Jahren. > > Alte Nachrichten sind aus dokumentarischen Gr�nden aber doch > interessant...
Interessant ist auch saurer Hering mit Schokoladensauce - es kommt doch darauf an, was man noch braucht. ;-) > > > > Den Index klein halten? Das geht notfalls auch mit NULL-Werten in > > > > Index-Spalten. Aber das lohnt sich wirklich nur in den > > > > F�llen, in denen > > > > man sehr viele Indexes auf den Tabellen bzw. Views hat und > > > > ganz bestimmt > > > > > > NULL-Werte heissen nicht NULL-Werte, weil sie NULL Platz brauchen... > > ;-) > > > Wieso kann man damit Platz sparen? Ausserdem ist der Index dann > > > nutzlos... > > > > Mit "IGNORE NULL" bei der Definition des Index wird tats�chlich kein > > Eintrag in der Index-Tabelle erzeugt und somit auch kein Speicherplatz > > verwendet. Es ist nicht zwangsl�ufig so, dass f�r jede Tabellenzeile > > auch eine Indexzeile angelegt wird. > > Super idee... Und wie finde ich dann die daten??? Auf jeden fall dann > nicht mehr �ber dem index... -> schlechte Idee! ??? z. B. "WHERE ... IS NULL" oder sonst irgendwas. Wenn man aber auch im "Archiv" schnell suchen will, l�sst man halt den Index bestehen. ;-) > > Das Lesen im Index macht nicht einmal 1% der gesamten Transaktionszeit > > f�r 100 Datens�tze aus, egal ob Du 100 oder 500.000 Datens�tze hast. > > > > Habe noch keine Erfahrung in die Richtung... Experimentiere mal mit dem Query-Analyzer und auch mit ASP/ADO. Die meiste Zeit geht daf�r drauf, die Datens�tze von der Platte zu lesen und zur Applikation zu senden. 150000 Datens�tze nach einem VARCHAR(50)-Feld zu sortieren dauert weniger als etwa eine halbe Sekunde (je nach Rechner). Die �bertragung dauert aber etwa 10 Sekunden. Nach dem TableScan im Speicher sortieren f�llt kaum ins Gewicht. Interessant sind dabei die Effekte, wenn ein Index sogar die Anwendung verlangsamt. Bei INSERT, UPDATE und DELETE ist das ja klar, aber auch bei einem SELECT kann das zus�tzliche Lesen der Index-Tabelle l�nger dauern, als das schnelle Sortieren im Speicher. Hier kommt es nat�rlich immer darauf an, wie lang ein Datensatz und wie lang der Index ist und wieviel RAM gerade zur Verf�gung steht. Bei mehreren Benutzern gleichzeitig ist ein Index im Cache sicher sehr n�tzlich und CPU-schonend. > Zusammenfassend kann man wohl sagen, dass man immer die Anforderungen > beachten muss, um konkrete Aussagen treffen zu k�nnen... Jo! 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
