È utile archiviare stringhe lunghe in un database?

Question

Devo archiviare stringhe lunghe in un database. la stringa può essere lunga 5 o 6 frasi. pensi che questa sia una buona strategia di progettazione. o dovrei archiviare un ID per quella stringa e quindi creare una relazione con un'altra tabella che contenga la posizione del file che memorizza la stringa. potresti per favore dare vantaggi e svantaggi di entrambi.

le stringhe sono state preelaborate e archiviate nel database. qualsiasi modifica leggerà l'intera stringa e la sostituirà completamente. quindi puoi presumere che la stringa sia indivisibile.

Answer 1

Dovrebbe andare bene memorizzare la stringa nel database. Se invece memorizzi un puntatore di file, ciò significa che devi fare I / O su file ogni volta che vuoi leggere la stringa. Alcune frasi non sono tremendamente lunghe e puoi sempre usare un campo dati longtext se necessario. Ovviamente il tuo database sarà un po 'più grande perché hai il testo, ma va bene. È certamente un'alternativa migliore rispetto a dover archiviare i file.

Answer 2

Le stringhe che menzioni non sono affatto lunghe.

Quando ti riferivi a " long " stringhe, stavo pensando a 32kB e oltre - alcune frasi sono < 1kb - non è niente oggi.

Il tuo trucco, la memorizzazione di un ID rende le cose più lente poiché devi effettuare un accesso indiretto.

L'unica cosa che consiglierei, quando sono necessarie le massime prestazioni, è necessario selezionare solo le colonne necessarie (omettere SELEZIONA *), quindi omettere la colonna di testo, quando non è necessaria, poiché il trasporto della stringa dal server all'applicazione costa il più tempo. È una buona prassi, non toccare le colonne non necessarie (specialmente quando potrebbero contenere molti dati).

Answer 3

L'unico motivo per cui creerei una tabella separata è se quelle stringhe lunghe saranno le stesse per molti record. Altrimenti è solo una complicazione aggiuntiva che non è in grado di fornire alcun rimborso.

Answer 4

Cinque o sei frasi non sono niente per un moderno DBMS! Memorizza il testo direttamente nel database.

(L'altra tecnica che hai citato - la memorizzazione di un riferimento in un'altra tabella che a sua volta ha un riferimento a un file esterno contenente il testo - sarebbe molto più ingombrante da usare e avrebbe prestazioni molto più scadenti.)

Answer 5

La risposta dipende davvero dal volume di stringhe che si intende archiviare e dal DB che si intende utilizzare per memorizzarla. Se non stai memorizzando molte stringhe, potresti prendere in considerazione la possibilità di memorizzarle in un file XML o di risorse e caricarle nell'applicazione in anticipo. Se hai molti dati sulle stringhe, probabilmente starai meglio leggendo la stringa in senso memory come e quando ne hai bisogno, piuttosto che cogliere la possibilità di leggere una stringa in memoria che non finisci per usare.

Answer 6

Il database stesso non ha problemi reali con la memorizzazione di stringhe lunghe. Si applicano alcune restrizioni (come il limite della dimensione del record 8k su SQL Server), ma anche in questo caso è possibile archiviare testo di lunghezza arbitraria in un database, poiché tutti quelli appropriati supportano tipi di dati BLOB / TEXT praticamente senza limite superiore.

Le 5-6 frasi non sono molto lunghe. Se appartengono insieme e devono essere recuperati e manipolati nel loro insieme, è possibile procedere e archiviarli in un campo del tipo di dati CHAR di dimensioni appropriate.

La domanda se separarli e allegare un ID a loro sorge solo se il tuo modello di applicazione / dati beneficia direttamente di questo approccio, cioè in realtà sono cose separate. Nel tuo caso non sembra esserci alcun motivo per procedere in questo modo.

Answer 7

Tutti hanno menzionato le prestazioni, ma nessuno ha sollevato l'altro motivo principale per cui archiviare i puntatori ai file del sistema operativo è una cattiva idea: backup e ripristino. Se tutto è nel database, allora abbiamo un singolo meccanismo per il backup dei dati e un singolo meccanismo per il recupero. Considerando che con i file sul sistema operativo abbiamo due diversi meccanismi di backup, probabilmente a due diverse granularità, e il recupero diventa un incubo di sincronizzazione.

Ci sono alcuni casi in cui questo non si applica, come i data warehouse, che hanno transazioni molto rare e quindi possono sopravvivere senza ripetere o registri delle transazioni.

Answer 8

Tranne casi speciali, lascerei il campo dov'è.

L'unica altra opzione sarebbe quella di mettere le stringhe in una tabella diversa (inserendo le stringhe effettive lì dentro) ... metterle in file separati ucciderà la tua performance.