Come dovrei valutare la soluzione di database per applicazioni di dati di grandi dimensioni

0

Sfondo
Mi è stato assegnato il compito di scrivere un'applicazione che sarà una combinazione di gestione di documenti e inventario in VB.net che verrà utilizzata per archiviare immagini di documenti in TIFF, PDF, XPS, TXT, DOC, PPT e così via come dati binari che possono essere recuperato per la visualizzazione, la stampa e l'eventuale OCR per essere ricercabile insieme ai metadati come mittente, destinatario, tipo di documento, data, fonte, ecc. Quindi la tabella sarebbe probabilmente qualcosa del tipo:

DOC_NAME, DOC_DATE, NOTE, ... DOC_BINARY (dove verrà inserito il documento effettivo)

Guida per favore Ho bisogno di aiuto per capire come valutare le opzioni del mio database.

Ciò che mi preoccupa è trovare una soluzione di database che non diventerà instabile a causa delle restrizioni sulle dimensioni, delle limitazioni e delle prestazioni dei record. Alcune delle opzioni sono MS_SQL, SQL Express, SQLite, mySQL e Access. Ora posso praticamente eliminare Access sin da quando è troppo limitante e non scalabile. Posso ulteriormente eliminare SQL Express a causa del limite di 2 GB e di nuovo della scalabilità.

Quindi credo che mi lasci con MS_SQL, SQLite e mySQL (nota, sono aperto alle alternative). Ed è qui che ho bisogno di aiuto per capire come valutare quei database.

L'obiettivo è che i dati si trovino tutti in un unico posto (un singolo file) che semplificherà il backup e la portabilità. Per l'utilizzo di piccoli volumi, praticamente tutte le soluzioni rimarranno valide per un po ', ma il mio obiettivo è quello di pensare al futuro e assicurarsi che sia in grado di sopportare anche l'uso di grandi volumi. Un'altra considerazione è anche l'interoperabilità con .NET e la stabilità di tale codice per evitare errori e perdite di memoria.

Come dovrei valutare le opzioni del mio database per questo scenario?

    
posta GµårÐïåñ 22.10.2013 - 22:59
fonte

1 risposta

2

Il limite di 2 gb è molto vecchio - IIRC era MSDE, che potevi chiamare Sql Express 2000. Il 2005 aveva 4 GB, il 2008 aveva 8 GB e credo che il 2012 abbia limiti di 10 gb.

In ogni caso, dal momento che tutto SQL Express è una versione di SQL Server, il percorso da intraprendere è creare / testare e distribuire per SQL Express e consentire agli utenti di eseguire l'upsize a SQL Server completi quando ne hanno bisogno. Finché la connessione al database è configurabile, si tratta di un cambiamento dell'impatto del codice zero.

La famiglia SQL Server presenta alcuni vantaggi per quello che vuoi fare - ci sono SKU gratuiti che dovrebbero farti uscire dal gate, l'integrazione VB.NET è dolce (anche se non ti aiuterà a evitare perdite di memoria) e il supporto FILESTREAM ti aiuterà a gestire i BLOB.

    
risposta data 22.10.2013 - 23:23
fonte

Leggi altre domande sui tag