Perché i database utilizzano il testo? [chiuso]

0

Questa potrebbe essere una domanda stupida, ma perché salviamo il testo nel db invece di qualcosa di più piccolo?

Non ci potrebbe essere un altro modo per memorizzare i dati nel db come in un modulo compresso, e poi avere "il nostro computer", che vuole i dati, decomprimere i dati dal db? Quello che voglio dire è mettere il carico sui computer e non sul db e sulla larghezza di banda.

Come diciamo, archiviamo il modulo compresso nel db e abbiamo tutto il calcolo fatto dal computer dell'utente. Quindi, se dovessimo fare un'istruzione select, la comprimessimo in qualcosa che solo il db capirà, e recupereremo i dati compressi che il nostro computer non comprerebbe e mostrerà nello stesso modo in cui lo otteniamo ora? o il testo è migliore?

Non sarebbe meglio considerare che di solito c'è molto carico sul db e che di solito può diventare piuttosto grande? ma se i dati fossero compressi già occuperebbero meno spazio almeno

    
posta Joe 31.08.2015 - 15:59
fonte

3 risposte

10

Stai mescolando serializzare con comprimere. È possibile utilizzare la serializzazione XML per memorizzare un modulo o una classe.

Puoi comprimere il testo e memorizzarlo in un file binario. Potresti ottenere tutta la compressione 7: 1. Per tale compressione si perde la capacità di cercare il testo che è lo scopo principale di un database.

    
risposta data 31.08.2015 - 16:43
fonte
6

Sei affetto da un problema comune tra gli ingegneri: quello dell'overottimizzazione in un frame. I due limiti classici del calcolo sono ora e spazio. Sono generalmente contrari; non puoi conservarne uno senza "spenderne" un altro. Il bug Y2K era in effetti un esempio di questo. I vincoli di spazio hanno reso i programmatori "salvano" due cifre nell'anno, aggiungendo "19" di fronte all'anno sono un calcolo (alias tempo). Allo stesso modo, stai suggerendo di risparmiare spazio comprimendo il file, consumando tempo di calcolo per risparmiare spazio sul disco.

A volte questo è valido. In effetti, una quantità significativa di TCP / IP è già compressa in modo trasparente con gzip in transito. Il tempo trascorso comprimendo & la decompressione è trascurabile rispetto alle risorse di rete richieste per trasferire un documento HTML non compresso.

Nel tuo caso, non lo è, per i seguenti motivi: L'archiviazione dei dati è economica rispetto al calcolo; Pensa al tuo computer oggi rispetto al tuo primo computer. Il mio primo computer (che ho acquistato da solo) era un processore da 120Mhz, con 16MB di RAM e un'unità da 1,2 Gb. Il mio attuale computer (un po 'invecchiato) ha una CPU da 3.6 Ghz, 32 GB di RAM e circa 16 TB di spazio di archiviazione. La CPU è 30 volte più veloce, ma la RAM è 2000x più grande (per non parlare di waaaay più veloce) e lo spazio di archiviazione è maggiore di 12500x. Gli attacchi Rainbow "decrittografia" sono un esempio di sfruttamento dello spazio per compensare i nostri difetti computazionali. Abbiamo ottenuto molto più spazio di quanto abbiamo tempo.

Secondo e più pratico: Se comprimi il testo in situ, perdi la capacità di cercarlo. A seconda dell'algoritmo di compressione e dei dati circostanti, la stringa "WKRP in Cincinnati" potrebbe essere compressa in un diverso set di caratteri, e la stringa simile "WKRP / Cincinnati" sarebbe quasi certamente diversa in qualsiasi cypher. Per cercare nel tuo database compresso, l'utente dovrebbe decomprimere (o dio non voglia, scaricare) l'intera cosa.

    
risposta data 31.08.2015 - 17:41
fonte
4

Beh, per uno si dovrebbe interrogare il db al di fuori del tuo programma piuttosto di una seccatura. Non credo che il leggero guadagno valga la pena di impegnarsi nel tempo, e questo include il supporto sul db in seguito.

Se il tuo obiettivo è una rapida ricerca, aggiungerai anche un sovraccarico alla ricerca.

Sicuramente se hai grandi blocchi di testo potrebbe valerne la pena, ma un approccio migliore potrebbe essere quello di separare i tuoi database o archiviarli più regolarmente.

    
risposta data 31.08.2015 - 16:06
fonte

Leggi altre domande sui tag