> > Hallo! > > Gut, argumentieren wir weiter; macht ja auch Spa�, oder? Jep.
> > > 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... > > > > 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! > > > > 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. > Habe noch keine Erfahrung in die Richtung... > > > 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. ;-) Aber noch nicht versekt ;-) > > > > 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? Hab ich vielleicht �berlesen... Zusammenfassend kann man wohl sagen, dass man immer die Anforderungen beachten muss, um konkrete Aussagen treffen zu k�nnen... Claudius | [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
