Storia vera
Il motivo più semplice per separare il contenuto più recente dai contenuti più vecchi è che il tuo database sta diventando grande. Alcuni anni fa sono stato coinvolto nella creazione di un'enorme applicazione finanziaria basata su un database preesistente. Conservava una varietà di dati fiscali, e aveva già diversi anni di dati in esso, quando sono stato coinvolto per la prima volta nel progetto. Avere un unico archivio di database con anni di dati ha senso solo quando ci sono effettivamente tutti questi dati, in qualsiasi momento. Il resto della squadra ha detto che era così, quindi non ci ho pensato molto.
Alcune settimane nel team ho capito che la realtà era leggermente diversa. I nostri utenti avevano solo bisogno di accedere ai dati dell'anno fiscale corrente, tranne:
- Quando si producono report annuali, qualcosa che è successo una volta all'anno
- Quando si producono rapporti di tre anni, qualcosa che è successo una volta ogni tre anni
Abbiamo deciso di suddividere il database in diversi database all'anno. Non è stata una decisione facile, ma ha funzionato: il database dell'anno fiscale corrente ha avuto risposte fulminee, poiché era solo la scansione di un sottoinsieme molto piccolo di tutti i dati. Le relazioni annuali sono state generate anche al volo, per lo stesso motivo. Le relazioni triennali erano un po 'più lente da generare rispetto a prima e ci voleva molta creatività per combinare tre archivi, ma quello era un piccolo svantaggio del processo.
Quindi il nostro database è stato diviso in piccoli database di archivio e tutti erano felici. (Non proprio, molti aspetti approssimativi e naturalmente questa è una versione semplificata della storia, ma nel complesso la decisione di archiviare è stata buona).
Dati eterogenei
Un altro motivo per archiviare è quando si ha una mancanza di omogeneità dei dati nel tempo. Quando lo schema del database cambia, specialmente per enormi database, la soluzione migliore è un database orientato ai documenti come MongoDB . I database orientati ai documenti hanno schemi flessibili, il che significa che non gli interessa se non si usano gli stessi campi per descrivere un record, quindi non si hanno campi vuoti come si farebbe con un database relazionale.
E come Jeff O note correttamente in un commento a altra risposta , i dati archiviati per definizione non cambieranno, quindi non è necessario preoccuparsi delle transazioni e di altre funzionalità relazionali. (Aggiunto qui, nel caso in cui il commento o la risposta vada in AWOL)
Archiviazione su siti Web orientati alle notizie
I siti web orientati alle notizie con molti dati possono scegliere di archiviare i loro contenuti più vecchi in un database orientato ai documenti, perché poiché trattano notizie, i loro contenuti più recenti sono molto più preziosi per loro dal punto di vista del business.
SEO & impaginazione
Infine, non ha nulla a che fare con la SEO e / o l'impaginazione (Pagination funzionerà indipendentemente da dove i tuoi contenuti sono archiviati). Un bot eseguirà la scansione del contenuto impaginato, seguendo i collegamenti di impaginazione come qualsiasi altro link. Se adotti uno schema URI ragionevole per tutti i tuoi contenuti, non hai nulla di cui preoccuparti. Ad esempio, immagina di avere un blog con dieci anni di articoli e hai deciso di spostare tutti gli articoli precedenti al 2010-12-31 in un archivio di archiviazione dei documenti.
La tua home page avrebbe probabilmente un elenco di articoli più recenti, qualcosa del tipo
http://example.com/articles/2011-11-1/title
http://example.com/articles/2011-10-30/title
http://example.com/articles/2011-10-20/title
Passando attraverso le pagine che finalmente imbattersi in una pagina:
http://example.com/articles/2011-1-1/title
http://example.com/articles/2010-12-30/title
http://example.com/articles/2010-12-25/title
Lo stesso schema URI, indipendentemente dal fatto che l'articolo sia memorizzato nel database corrente o nel database di archivio. Tutto quello che devi fare è un semplice controllo lato server quando i tuoi visitatori (umani o bot) cliccano sull'articolo 2010-12-30:
if(date <= 2010-12-31) {
// get article information from archive
} else {
// get article information from current database
}
Ora perché alcuni siti possono scegliere di spostare il contenuto archiviato in una sezione di archivio speciale, è qualcosa che è comprensibile solo a coloro che li hanno creati. Potrebbero esserci alcuni fattori di esperienza utente coinvolti, ma questo è fuori tema per i programmatori, puoi provare a interrogare la gente all'indirizzo Scambio pila esperienza utente .