Hallo! Gut, argumentieren wir weiter; macht ja auch Spa�, oder?
> 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. > > 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. > > nicht bei einer News-Tabelle, oder? Im Bin�rbaum braucht's schon sehr > > viel mehr Daten, damit man den Unterschied auch merkt (2er Potenzen). > > > > Jeden Tag eine neue News macht in 100 Jahren 36.500 News. > > Schon klar... Ich kann mir aber auch ein Beispiel ausdenken, bei dem es > Sinn macht... Mitunter gibt es ja auch Archivierungspflichten (z. B. GOSB) ... Jetzt die Diskussion nicht unn�tig in die L�nge ziehen - man kann sich ja viel ausdenken, und ganz sicher kannst Du Dir einfacher Beispiele ausdenken, wo es keinen Sinn macht. > Ich kenn nicht die Newsmengen, f�r die das ausgelegt sein soll... > Beispiel Internationale Nachrichtenagentur.... 100 News pro Tag... Nach > drei Jahren also ca. 100000. Wenn ich jetzt vielen Usern die Nachrichten > der letzte Woche bereitstellen will, dann kann es schon einen > Unterschied machen, ob ich im B*-Baum einen Startpunkt in 700 oder > 100000 Nachrichten suchen muss... ca. doppelt so schnell... Stimmt, aber alles noch im Bereich von nicht einmal einer Millisekunde. 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. > > Die News der > > letzten 7 Tage brauchen allerdings gar keine Indexes (fr�hestens ab 50 > > Datens�tze). > > Das versteh ich mal als Grund die Daten auszulagern... Weil nur dann > kann man die Anzahl so tief halten, dass die DB keinen Index braucht, > weil sie mit einenm TableScan schneller ist... Treffer - ich hatte bef�rchtet, dass das Argument kommt. ;-) > > Und zwei identische Tabellen zu warten geht irgendwann einmal schief, > > weil dann einer in Tabelle A eine Spalte einf�gt oder �ndert > > und das f�r > > Tabelle B vergisst. Eine Tabelle und zwei Views sind da doch > > wesentlich > > eleganter. > > Ja... > Ist alles eine Frage der Anforderungen... Manchmal muss man in den > sauren Apfel beissen und Eleganz gegen Performance tauschen... > Aber es gibt ja auch noch indizierte Views... Das w�re bei > entsprechenden Scenario und DB wohl die beste L�sung... Klar, 1 Tabelle, 2 Views mit Indexes. Sagte ich das nicht? 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
