Un database "leggero"

giovedì 10 ottobre 2013 - 16.11

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags C# | .NET 3.5 | Windows 7 | Visual Studio 2010

marco.morgia Profilo | Junior Member

73 messaggi | Data Invio: gio 10 ott 2013 - 16:11

Ciao,

devo realizzare un software che ad intervalli prestabiliti ( si parla di ore ) vado a leggere o scrivere su un database. Quindi, come già successo in altre occasioni, ho utilizzato SqlCompact.

Il problema è nato quando, il mio database non deve essere accessibile da una sola postazione ma da più postazioni. Ovviamente SQLcompact non supporta questo tipo di connessioni.

Vorrei qualche consiglio su che tipo di database utilizzare. So che l'ideale è un DB Server come SQL o MySql, ma a me serve necessariamente qualcosa di molto più leggero,come SQLce ma che supporti connessioni da più client

Grazie

ridaria Profilo | Expert

905 messaggi | Data Invio: gio 10 ott 2013 - 17:21

ma che intendi con la definizione di "LEGGERO"'

ciao a presto
Riccardo D'Aria

marco.morgia Profilo | Junior Member

73 messaggi | Data Invio: lun 14 ott 2013 - 08:47

Buongiorno,

con Leggero intendo che non necessiti di nessuna configurazione ( tipo SQL o MySql ).

Avevo pensato anche ad Access sinceramente, ma non so se posso usarlo per lo sviluppo di applicazioni commerciali.

ridaria Profilo | Expert

905 messaggi | Data Invio: lun 14 ott 2013 - 14:54

ok dunque, diciamo che posto che la scelta dovrebbe comunque ricadere sul migliore database,

detto ciò quindi, a mio avviso la discriminante è la seguente:

La portabilità del DB.

Ove per portabilità si intende la caratteristica del db di essere velocemente e facilmente installato sui computers su cui va utilizzato.
Quindi se va installato su molti computers percheè si tratta di una applicazione di ampia distribuzione, allora deve prediligersi la portabilità.
In questi casi va da se anche che essendo molti pc su cui installare, accade anche, e non di rado, di trovare pc con S.O. danneggiati, appesantiti o danneggiati.
Si pensi anche ai casi in cui le installazioni vengono fatte dagli utenti finali e non da te (sviluppatore del software)
POsto ciò dunque, la portabilità deve predominare sulla qualità del DB. E quindi la scelta deve ricadede su ACCESS/SQLCE dove preferisco access a SQLce.

Nella situazione opposta io consiglio SQL Server 2008 R2 di casa Microsoft.

Per ciò che attiene access, una volta installato il software, che reca con se il file di database, sul PC in questione, non necessita affatto che ci sia ACCESS installato, quindi non vi sono problemi di licenze varie.

Spero di essere stato chiaro.

CIAO fammi sapere :-)

Riccardo D'Aria

dompa72 Profilo | Senior Member

245 messaggi | Data Invio: mar 15 ott 2013 - 13:21

>ok dunque, diciamo che posto che la scelta dovrebbe comunque
>ricadere sul migliore database,
>
>detto ciò quindi, a mio avviso la discriminante è la seguente:
>
>La portabilità del DB.
>
>Ove per portabilità si intende la caratteristica del db di essere
>velocemente e facilmente installato sui computers su cui va utilizzato.
>Quindi se va installato su molti computers percheè si tratta
>di una applicazione di ampia distribuzione, allora deve prediligersi
>la portabilità.
>In questi casi va da se anche che essendo molti pc su cui installare,
>accade anche, e non di rado, di trovare pc con S.O. danneggiati,
>appesantiti o danneggiati.
>Si pensi anche ai casi in cui le installazioni vengono fatte
>dagli utenti finali e non da te (sviluppatore del software)
>POsto ciò dunque, la portabilità deve predominare sulla qualità
>del DB. E quindi la scelta deve ricadede su ACCESS/SQLCE dove
>preferisco access a SQLce.
>
>Nella situazione opposta io consiglio SQL Server 2008 R2 di casa
>Microsoft.
>
>Per ciò che attiene access, una volta installato il software,
>che reca con se il file di database, sul PC in questione, non
>necessita affatto che ci sia ACCESS installato, quindi non vi
>sono problemi di licenze varie.

Va bene tutto ma non è molto consigliato ad accessi multipli e da postazioni diverse, si risolve con le condivisioni di rete, ma personalmente lo sconsiglio
Per il resto consiglio SQLServer versione Express (versione 2008R2 10 utenti contemporanei e 10 GB spazio database) senza spendere nulla
Sempre senza spendere nulla si può optare per PostgreSQL, se è possibile spendere qualcosa straconsiglio SQLServer

Ciao

>
>
>Spero di essere stato chiaro.
>
>CIAO fammi sapere :-)
>
>
>
>
>Riccardo D'Aria

marco.morgia Profilo | Junior Member

73 messaggi | Data Invio: mer 16 ott 2013 - 08:16

Grazie a tutti per i consigli, sono stati veramente ben accetti.

Il fatto di non utilizzare un database SQLServer ( che anche io preferirei di gran lunga ) è dovuto alla presenza di database che possono essere MySql o Firebird. Sinceramente montare su un'altra architettura con SqlServer potrebbe creare un po' di confusione a livello sistemistico.

Esclusa anche l'ipotesi di creare 2 diversi tipi di programmi ( uno con MySql e Uno con Firebird ) perché quei database sono intoccabili. Inizialmente infatti avevo anche pensato di utilizzare entities ( visto che esistono i connector sia per MySql e Firebird ) per poi cambiare la stringa di connessione a Runtime, ma l'idea è stata bocciata.

Inoltre si richiede che il programma sia di semplice installazione ( ecco perché anche SqlServer non va bene ) .

L'unica cosa rimasta, anche se non è la più pulita , è Access, sapendo che si andrà incontro a problemi di "affidabilità" usandolo su più istanze.

dompa72 Profilo | Senior Member

245 messaggi | Data Invio: mer 16 ott 2013 - 08:44

>Grazie a tutti per i consigli, sono stati veramente ben accetti.
>
>
>Il fatto di non utilizzare un database SQLServer ( che anche
>io preferirei di gran lunga ) è dovuto alla presenza di database
>che possono essere MySql o Firebird. Sinceramente montare su
>un'altra architettura con SqlServer potrebbe creare un po' di
>confusione a livello sistemistico.
Perchè non utilizzare MySQL direttamente (Firebird lo conosco di nome), aggiungi un altro database ed utilizzi quello eventualmente anche con utenti dedicati
>
>Esclusa anche l'ipotesi di creare 2 diversi tipi di programmi
>( uno con MySql e Uno con Firebird ) perché quei database sono
>intoccabili. Inizialmente infatti avevo anche pensato di utilizzare
>entities ( visto che esistono i connector sia per MySql e Firebird
>) per poi cambiare la stringa di connessione a Runtime, ma l'idea
>è stata bocciata.
Non dico di utilizzare i loro database ma di aggiungerne uno al motore
>
>Inoltre si richiede che il programma sia di semplice installazione
>( ecco perché anche SqlServer non va bene ) .
Non vedo la difficoltà, forse solo di costi, ma vengono ripagati anche con l'utilizzo di SSIS
>
>L'unica cosa rimasta, anche se non è la più pulita , è Access,
>sapendo che si andrà incontro a problemi di "affidabilità" usandolo
>su più istanze.
Per me Access resta un prodotto stand alone, ho lavorato con access in rete (cartella condivisa) e richiede molta manutenzione
Per portabilità di access è vero che puoi rilasciare il tutto con il pacchetto, ma solo se il Path di accesso è conosciuto prima dell'installazione, se viene utilizzato in rete dovrai condividere la cartella dove è presente il file e sopratutto concedere diritti di Lettura e scrittura all'utente connesso al PC, questo comporta che l'utente può accedere direttamente al file aprendo la cartella condivisa e può fare quello che vuole (può anche eliminare il file). A me è successo, per fortuna aveva solo spostato il file altrimenti si perdeva il lavoro dell'intera giornata (recupero da Backup)
Sicuramente Access facilita il lavoro ma se i dati crescono diventa necessario compattarlo di frequente, con il rischio di perdere tutto con delle cadute di rete
Per questi motivi ne sto alla larga dalla versione 2003
>
>
>
Ciao e naturalmente le mie sono considerazioni su esperienze personali

marco.morgia Profilo | Junior Member

73 messaggi | Data Invio: mer 16 ott 2013 - 09:03

Hahahaha hai ragione su tutto.

Allora il discorso è che bisogna renderlo quanto più stand-alone possibile. Quindi dovrebbe funzionare anche per chi non ha access o mysql.

Per quanto riguarda il discorso delle cartelle condivise non è un problema, il database andrà già in una cartella strutturata in quel modo ( cioè con diritti di scrittura e condivisioni varie )

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !