> > Hallo! > > > > > Ich habe eine News- Tabelle (ueberschrift, untertitel, etc... ) > und > > > m�chte > > > > alle Eintr�ge, die �lter als 1 Woche sind ( feldname= > > > "erscheinungsdatum") > > > > in eine schon angelegte, strukturgleiche Archiv-Tabelle > verschieben. > > > > > > > > Habt Ihr da mal den SQL-Befehl f�r mich ? > > > > > > Warum 2 Tabellen? > > > > > > Arbeitsbeschaffungsprogramm f�r wenig ausgelastete Datenbanken??? > > > > *LOL* > > > > Naja... Es kann schon Sinn machen.... > > Wenn man die alten Daten wirklich nicht mehr zum arbeiten > braucht kann > > man so die Tabelle und somit den Index klein halten... > > Daten, die man nicht mehr braucht, w�rde ich einfach l�schen. ;-)
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... > > 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... > 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... 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... > 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... > > 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... Gruss, Claudius > > 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 > | [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
