C'è uno svantaggio nell'usare Access come database?

I database MSAccess in genere non vengono utilizzati per un paio di motivi. In passato, erano instabili e non accettavano più connessioni contemporaneamente. Quando viene utilizzato il database MSAccess, viene creato un file di blocco (ldb). Quando il file di blocco è presente, nessun altro può accedere al database. Ho scoperto che quando c'era un'applicazione monouso, le prestazioni di MSAccess si degradavano gravemente dopo circa 50.000 file. Probabilmente è meglio ora, ma certamente non è stato ottimizzato per usi più ampi.

La cosa più tipica è usare un sistema di database più robusto come postgres, mysql o MSSQL. Per i database a connessione singola, ho usato Derby (con Java).

Per quanto riguarda VB, non troverai soluzioni professionali che utilizzano VB come software client in un database. Bene, forse ci sono alcune soluzioni in vendita, ma personalmente, vorrei evitarle.

Tipicamente, l'elaborazione verrà eseguita in un linguaggio come C #, C ++, Java, Perl, Python o altri linguaggi popolari. Le librerie saranno utilizzate per connettersi al database che sono separati dalla lingua. Alcune soluzioni utilizzeranno SQL per interrogare e ricevere dati e altre soluzioni utilizzeranno una libreria di Persistenza per creare oggetti dai dati (questo sta diventando più comune).

Per quanto riguarda le migliori pratiche, ho sempre trovato la cosa migliore per essere coerente. Se hai un negozio di quattro persone che capiscono MSAccess e VisualBasic, allora ha molto senso continuare a farlo in questo modo. Se c'è un obiettivo nella società di allontanarsi da esso a causa di errori nel passato, è possibile continuare a utilizzare VB e passare a un altro database. Esaminare le tabelle di collegamento in MSAccess: ho utilizzato un'applicazione VB su un database MSSQL collegando le tabelle MSSQL a un database MSAccess. Il VB non conosceva la differenza tra una tabella MSAccess ingenua e una tabella collegata situata su un altro server. La soluzione VB era ancora instabile, ma funzionava molto meglio con dataset più grandi.

Spero che questo aiuti!

Ho avuto alcune esperienze riguardo a questo problema in passato in una grande azienda.

Con l'aumentare della base di utenti, sono emersi problemi di sicurezza e prestazioni perché i file di Access in cui i dati risiedevano dovevano essere archiviati in una cartella condivisa di rete e tutti gli utenti dovevano avere accesso W / R ad esso .

Questo non è teorico, questa è esperienza del mondo reale, I database di accesso non si adattano bene a decine di utenti simultanei, figuriamoci un paio di centinaia distribuiti geograficamente.

Con i sistemi di database gratuiti e di buona qualità come PostgreSQL disponibili, ci sono pochi motivi per accedere ad Access eccetto quanto segue: mancanza di know how tecnico.

Personalmente se sei in grado di allontanarti dall'accesso fallo, ho avuto clienti che hanno sofferto davvero perché semplicemente non potevano o non volevano "mordere il proiettile".

Siccome Kieveli ha detto che i database di Access sono orribili quando si tratta di immagazzinare grandi quantità di dati, le applicazioni dovrebbero essere sempre progettate con il vantaggio per l'utente finale. Immagina di avere un ufficio pieno di persone che hanno un sistema orribilmente lento che spreca ore del loro tempo ogni settimana?

Parlare dall'esperienza personale lo spostamento di un database di accesso a SQL Server non è davvero doloroso se si pianifica correttamente, la domanda è se si hanno le competenze tecniche interne per passare a qualcosa come vb.net ecc.

I database di accesso non sono scalabili, ma sono facili da gestire e distribuire. Se si utilizza un Object Relational Mapper (O / R-mapper) che supporta diversi tipi di database come interfaccia per il proprio database, la propria applicazione sarà molto meno dipendente da uno specifico tipo di database. Ciò ti consente di iniziare con Access e di spostarti in un altro database più tardi.

L'ho fatto una volta e ho avviato un progetto con Access e un front-end C #, perché i database possono essere configurati e sviluppati molto facilmente con Access. Successivamente sono passato a un database Oracle perché il mio cliente ha un database Oracle. Solo alcune modifiche dove richiesto nella mia applicazione.

Jet-SQL è orribilmente documentato. Solo questo è un motivo per me di stare lontano da Access.

link

T-SQL (SQL Server) d'altra parte è molto più flessibile e puoi trovare tonnellate di documentazione, blog ed esperti che possono aiutarti.

Ovviamente Access è un database desktop mentre SQL Server è un database client-server completo.

Ci sono altri database desktop là fuori (ho usato Advantage Database Server, ma anche questo è un prodotto di nicchia).