Mantis-89
26-03-2010, 16:21
Tra MySQL, PostgreSQL e FireBirdSQL quale scegliereste e perchè?
View Full Version : [SQL] MySQL, PostgreSQL e FireBirdSQL: Quale scegliere?
CozzaAmara
26-03-2010, 17:15
Tra MySQL, PostgreSQL e FireBirdSQL quale scegliereste e perchè?
Dipende, sono tre ottimi RDBMS.
MySQL: vastissima documentazione, molto veloce per piccole basi dati.
Postgres: completamente gratuito e molto maturo.
FirebirdSQL: non lo conosco ma ricordo che sia il preferito di cdimauro :D
Dipende, sono tre ottimi RDBMS.
MySQL: vastissima documentazione, molto veloce per piccole basi dati.
Postgres: completamente gratuito e molto maturo.
FirebirdSQL: non lo conosco ma ricordo che sia il preferito di cdimauro :D
lupoxxx87
26-03-2010, 17:43
nessuno è meglio e nessuno è peggio ....
dipende dal sistema operativo e dall'utilizzo soprattutto...
un mio prof citava sempre questa frase quando dovevamo scegliere qualcosa
“Ogni uomo deve cercare senza sterili imitazioni il suo modo di vivere la verità”
Siddarta
dipende dal sistema operativo e dall'utilizzo soprattutto...
un mio prof citava sempre questa frase quando dovevamo scegliere qualcosa
“Ogni uomo deve cercare senza sterili imitazioni il suo modo di vivere la verità”
Siddarta
Mantis-89
26-03-2010, 18:25
Intanto grazie per le risposte.
Come OS principale avrei Windows però non escludo di utilizzare anche Linux (o BSD).
L'applicazione che vorrei scrivere per adesso dovrebbe essere in c# (anche se prevedo di riscriverla in Java più avanti) e il database che andrebbe ad utilizzare non sarebbe tanto grande.
Quale tra questi rispetta meglio lo standard SQL?
Quale è più semplice da installare/configurare?
E quale dispone di tool di configurazione migliori?
PS:A lavoro utilizzo MS SQL Server 2005 e (purtroppo) mi trovo bene.
Grazie :D
Come OS principale avrei Windows però non escludo di utilizzare anche Linux (o BSD).
L'applicazione che vorrei scrivere per adesso dovrebbe essere in c# (anche se prevedo di riscriverla in Java più avanti) e il database che andrebbe ad utilizzare non sarebbe tanto grande.
Quale tra questi rispetta meglio lo standard SQL?
Quale è più semplice da installare/configurare?
E quale dispone di tool di configurazione migliori?
PS:A lavoro utilizzo MS SQL Server 2005 e (purtroppo) mi trovo bene.
Grazie :D
lupoxxx87
26-03-2010, 18:32
a mio parere quei 3 vanno bene su un ambiene unix, non su windows...
se devi lavorare su windows ti consiglio oracle, che non ha problemi di stabilità (e ci mancherebbe altro...con quello che costano le licenze per la full version), però è anche abbastanza pesantuccio...
se devi salvare pochi dati potresti dare un'occhiata ai db non relazionali....
o se i dati che devi salvare sono proprio pochi prova con sqlite
se devi lavorare su windows ti consiglio oracle, che non ha problemi di stabilità (e ci mancherebbe altro...con quello che costano le licenze per la full version), però è anche abbastanza pesantuccio...
se devi salvare pochi dati potresti dare un'occhiata ai db non relazionali....
o se i dati che devi salvare sono proprio pochi prova con sqlite
cionci
26-03-2010, 18:34
Puoi sempre usare MS SQL Express se ti interessa lavorare sull'applicazione che usi a lavoro. Anche perché è chiaro che non siano affatto interscambiabili.
Mantis-89
26-03-2010, 18:52
Puoi sempre usare MS SQL Express se ti interessa lavorare sull'applicazione che usi a lavoro. Anche perché è chiaro che non siano affatto interscambiabili.
MS SQL Express non mi piace (detesto le versioni castrate, sopratutto se ti limitano nell'uso e non solo sulle funzionalità, mi riferisco ai 4 GB) e non devo lavorare con l'applicazione che uso a lavoro ma scriverne una mia.
a mio parere quei 3 vanno bene su un ambiene unix, non su windows...
:(
se devi lavorare su windows ti consiglio oracle, che non ha problemi di stabilità (e ci mancherebbe altro...con quello che costano le licenze per la full version), però è anche abbastanza pesantuccio...
Vorrei rimanere su qualcosa di gratuito e distribuibile
se devi salvare pochi dati potresti dare un'occhiata ai db non relazionali....
o se i dati che devi salvare sono proprio pochi prova con sqlite
Si non andrò a trattare una mole di dati enorme (credo verrà fuori qualcosa come 3 tabelle di sistema, 3-6 tabelle di dati con una velocità di crescita di 400 record al giorno) però mi serve un database relazionale che lavori in rete e in multi utenza (la concorrenza la gestirò a livello di applicazione)
Grazie
MS SQL Express non mi piace (detesto le versioni castrate, sopratutto se ti limitano nell'uso e non solo sulle funzionalità, mi riferisco ai 4 GB) e non devo lavorare con l'applicazione che uso a lavoro ma scriverne una mia.
a mio parere quei 3 vanno bene su un ambiene unix, non su windows...
:(
se devi lavorare su windows ti consiglio oracle, che non ha problemi di stabilità (e ci mancherebbe altro...con quello che costano le licenze per la full version), però è anche abbastanza pesantuccio...
Vorrei rimanere su qualcosa di gratuito e distribuibile
se devi salvare pochi dati potresti dare un'occhiata ai db non relazionali....
o se i dati che devi salvare sono proprio pochi prova con sqlite
Si non andrò a trattare una mole di dati enorme (credo verrà fuori qualcosa come 3 tabelle di sistema, 3-6 tabelle di dati con una velocità di crescita di 400 record al giorno) però mi serve un database relazionale che lavori in rete e in multi utenza (la concorrenza la gestirò a livello di applicazione)
Grazie
lupoxxx87
26-03-2010, 19:38
se hai un server linux ti consiglio 1) postgres 2) mysql...
se hai un server windows c'è una versione free di oracle...la express
se hai un server windows c'è una versione free di oracle...la express
cionci
26-03-2010, 20:22
Ma di che tipo di prestazioni hai bisogno ?
anto_demeter
26-03-2010, 21:41
Ho avuto a che fare con postgres (per l'università) e tutt'ora con MySQL.
Ti dico alcuni degli aspetti in cui mi sono imbattuto:
immediatamente le differenze che si presentano riguardano la documentazione che molto più consistente nel caso di MySQL.
La seconda differenza è più di tipo tecnico....secondo me la struttura di Postgresql è molto pi ben fatta vedi Trigger e foreign key (ad esempio) molto più semplici da fare con postgres.
Per quanto riguarda la velocità, e credo non sia solo un mio parere, MySQL tutta la vita!!
In definitiva ti dico che nonostante la migliore struttura che da vincente postgres io ti consiglierei tra i due MySQL, molto più diffuso, molto più veloce e performante e molta molta più documentazione online!
tutto ovviamente ImHo
Ti dico alcuni degli aspetti in cui mi sono imbattuto:
immediatamente le differenze che si presentano riguardano la documentazione che molto più consistente nel caso di MySQL.
La seconda differenza è più di tipo tecnico....secondo me la struttura di Postgresql è molto pi ben fatta vedi Trigger e foreign key (ad esempio) molto più semplici da fare con postgres.
Per quanto riguarda la velocità, e credo non sia solo un mio parere, MySQL tutta la vita!!
In definitiva ti dico che nonostante la migliore struttura che da vincente postgres io ti consiglierei tra i due MySQL, molto più diffuso, molto più veloce e performante e molta molta più documentazione online!
tutto ovviamente ImHo
cionci
26-03-2010, 21:49
Di MySQL c'è anche da considerare il tipo di licenza se fai un'applicazione di tipo commerciale. Infatti non è gratuito per applicazioni commerciali.
Mantis-89
27-03-2010, 00:18
Per quanto riguarda le prestazioni non ho particolari esigenze.
Per quanto rigurda MySQL mi sembra si possa utilizzare gratuitamente anche per scopi commerciali perchè la versione gratuita è distribuita secondo la GPL.
Per quanto rigurda MySQL mi sembra si possa utilizzare gratuitamente anche per scopi commerciali perchè la versione gratuita è distribuita secondo la GPL.
cionci
27-03-2010, 00:26
Per quanto rigurda MySQL mi sembra si possa utilizzare gratuitamente anche per scopi commerciali perchè la versione gratuita è distribuita secondo la GPL.
Mi sono spiegato male. E' utilizzabile gratuitamente per scopi commerciali a patto di rilasciare il codice sorgente a cui è linkata la libreria client e il connector sotto GPL.
E' vero che non necessariamente GPL significa gratuito, ma è altrettanto vero che linkare codice GPL in un software commerciale è un bel problema.
Qualche anno fa era rilasciato sotto forma di LGPL e non c'erano di questi problemi.
Mi sono spiegato male. E' utilizzabile gratuitamente per scopi commerciali a patto di rilasciare il codice sorgente a cui è linkata la libreria client e il connector sotto GPL.
E' vero che non necessariamente GPL significa gratuito, ma è altrettanto vero che linkare codice GPL in un software commerciale è un bel problema.
Qualche anno fa era rilasciato sotto forma di LGPL e non c'erano di questi problemi.
cdimauro
27-03-2010, 05:49
Dipende, sono tre ottimi RDBMS.
MySQL: vastissima documentazione, molto veloce per piccole basi dati.
Postgres: completamente gratuito e molto maturo.
FirebirdSQL: non lo conosco ma ricordo che sia il preferito di cdimauro :D
:rotfl: Vero, e fra i 3 è il più maturo, visto che deriva direttamente dai sorgenti di InterBase (RDBMS di classe enterprise venduto dalla ex Borland).
Intanto grazie per le risposte.
Come OS principale avrei Windows però non escludo di utilizzare anche Linux (o BSD).
L'applicazione che vorrei scrivere per adesso dovrebbe essere in c# (anche se prevedo di riscriverla in Java più avanti) e il database che andrebbe ad utilizzare non sarebbe tanto grande.
Quale tra questi rispetta meglio lo standard SQL?
Firebird sicuramente: si pone proprio l'obiettivo della maggior aderenza possibile agli standard.
Quale è più semplice da installare/configurare?
Setup, Avanti, Avanti, Fine. :D
Inoltre è disponibile anche in versione embedded, eventualmente (non è il tuo caso, ma è giusto che tu lo sappia): quindi zero installazioni.
E quale dispone di tool di configurazione migliori?
Firebird condivide in parte quelli di InterBase, e ce ne sono diversi dotati spesso di interfaccia grafica.
Ho avuto a che fare con postgres (per l'università) e tutt'ora con MySQL.
Ti dico alcuni degli aspetti in cui mi sono imbattuto:
immediatamente le differenze che si presentano riguardano la documentazione che molto più consistente nel caso di MySQL.
La seconda differenza è più di tipo tecnico....secondo me la struttura di Postgresql è molto pi ben fatta vedi Trigger e foreign key (ad esempio) molto più semplici da fare con postgres.
Per quanto riguarda la velocità, e credo non sia solo un mio parere, MySQL tutta la vita!!
In definitiva ti dico che nonostante la migliore struttura che da vincente postgres io ti consiglierei tra i due MySQL, molto più diffuso, molto più veloce e performante e molta molta più documentazione online!
tutto ovviamente ImHo
Per quanto riguarda le prestazioni è tutto da vedere. Se parliamo di database transazionali, non credo ci sia storia fra MySQL e FireBird/PostgreSQL.
FireBird poi ha un engine multitransazionale di tipo ottimistico. Giusto per fare un esempio: prova a modificare lo schema di una tabella con MySQL e poi con FireBird, e vedi la differenza che c'è (specialmente se ci sono parecchi dati). Con MySQL il lock è sempre in agguato; con FireBird NO! :cool:
Mi sono spiegato male. E' utilizzabile gratuitamente per scopi commerciali a patto di rilasciare il codice sorgente a cui è linkata la libreria client e il connector sotto GPL.
E' vero che non necessariamente GPL significa gratuito, ma è altrettanto vero che linkare codice GPL in un software commerciale è un bel problema.
Qualche anno fa era rilasciato sotto forma di LGPL e non c'erano di questi problemi.
Meglio FireBird da questo punto di vista, che ha una licenza Mozilla/BSD-like.
MySQL: vastissima documentazione, molto veloce per piccole basi dati.
Postgres: completamente gratuito e molto maturo.
FirebirdSQL: non lo conosco ma ricordo che sia il preferito di cdimauro :D
:rotfl: Vero, e fra i 3 è il più maturo, visto che deriva direttamente dai sorgenti di InterBase (RDBMS di classe enterprise venduto dalla ex Borland).
Intanto grazie per le risposte.
Come OS principale avrei Windows però non escludo di utilizzare anche Linux (o BSD).
L'applicazione che vorrei scrivere per adesso dovrebbe essere in c# (anche se prevedo di riscriverla in Java più avanti) e il database che andrebbe ad utilizzare non sarebbe tanto grande.
Quale tra questi rispetta meglio lo standard SQL?
Firebird sicuramente: si pone proprio l'obiettivo della maggior aderenza possibile agli standard.
Quale è più semplice da installare/configurare?
Setup, Avanti, Avanti, Fine. :D
Inoltre è disponibile anche in versione embedded, eventualmente (non è il tuo caso, ma è giusto che tu lo sappia): quindi zero installazioni.
E quale dispone di tool di configurazione migliori?
Firebird condivide in parte quelli di InterBase, e ce ne sono diversi dotati spesso di interfaccia grafica.
Ho avuto a che fare con postgres (per l'università) e tutt'ora con MySQL.
Ti dico alcuni degli aspetti in cui mi sono imbattuto:
immediatamente le differenze che si presentano riguardano la documentazione che molto più consistente nel caso di MySQL.
La seconda differenza è più di tipo tecnico....secondo me la struttura di Postgresql è molto pi ben fatta vedi Trigger e foreign key (ad esempio) molto più semplici da fare con postgres.
Per quanto riguarda la velocità, e credo non sia solo un mio parere, MySQL tutta la vita!!
In definitiva ti dico che nonostante la migliore struttura che da vincente postgres io ti consiglierei tra i due MySQL, molto più diffuso, molto più veloce e performante e molta molta più documentazione online!
tutto ovviamente ImHo
Per quanto riguarda le prestazioni è tutto da vedere. Se parliamo di database transazionali, non credo ci sia storia fra MySQL e FireBird/PostgreSQL.
FireBird poi ha un engine multitransazionale di tipo ottimistico. Giusto per fare un esempio: prova a modificare lo schema di una tabella con MySQL e poi con FireBird, e vedi la differenza che c'è (specialmente se ci sono parecchi dati). Con MySQL il lock è sempre in agguato; con FireBird NO! :cool:
Mi sono spiegato male. E' utilizzabile gratuitamente per scopi commerciali a patto di rilasciare il codice sorgente a cui è linkata la libreria client e il connector sotto GPL.
E' vero che non necessariamente GPL significa gratuito, ma è altrettanto vero che linkare codice GPL in un software commerciale è un bel problema.
Qualche anno fa era rilasciato sotto forma di LGPL e non c'erano di questi problemi.
Meglio FireBird da questo punto di vista, che ha una licenza Mozilla/BSD-like.
cionci
27-03-2010, 07:48
Per quanto riguarda le prestazioni è tutto da vedere. Se parliamo di database transazionali, non credo ci sia storia fra MySQL e FireBird/PostgreSQL.
Concordo. MySQL è veloce soprattutto su tabelle MyISAM, le tabelle InnoDB non eccellono assolutamente per prestazioni.
Con MySQL il lock è sempre in agguato; con FireBird NO! :cool:
Spiega un po' meglio... Intendi il lock a livello di tabella usato sulle MyISAM ?
Meglio FireBird da questo punto di vista, che ha una licenza Mozilla/BSD-like.
PostgreSQL ha addirittura licenza BSD ;)
Per PostgreSQL sarebbe interessante provare questa distribuzione (tutti i tool e tutti i connector sono inclusi): http://www.enterprisedb.com/products/postgres_plus/download.do
Mantis: secondo me bisogna valutare bene anche come, da C#, ci si connette al DB.
Per PostgreSQL c'è questo: http://npgsql.projects.postgresql.org/
Sinceramente non ne conosco le prestazioni.
Per MySQL c'è il .Net Connector sul sito ufficiale.
Per Firebird c'è questo: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Peccato che attualmente siano irraggiungibili sia le api che il tutorial.
Ecco, quello che non mi è mai piaciuto di Firebird è una certa confusione nella documentazione e soprattutto nelle metodologie di connessione con i vari linguaggi. Nelle release notes si parla di versione 2.5.x. Il link mancante è alle API 1.7. La feature list è della versione 1.6 :D
Al contrario uno dei punti di forza di PostgreSQL è proprio al documentazione.
Concordo. MySQL è veloce soprattutto su tabelle MyISAM, le tabelle InnoDB non eccellono assolutamente per prestazioni.
Con MySQL il lock è sempre in agguato; con FireBird NO! :cool:
Spiega un po' meglio... Intendi il lock a livello di tabella usato sulle MyISAM ?
Meglio FireBird da questo punto di vista, che ha una licenza Mozilla/BSD-like.
PostgreSQL ha addirittura licenza BSD ;)
Per PostgreSQL sarebbe interessante provare questa distribuzione (tutti i tool e tutti i connector sono inclusi): http://www.enterprisedb.com/products/postgres_plus/download.do
Mantis: secondo me bisogna valutare bene anche come, da C#, ci si connette al DB.
Per PostgreSQL c'è questo: http://npgsql.projects.postgresql.org/
Sinceramente non ne conosco le prestazioni.
Per MySQL c'è il .Net Connector sul sito ufficiale.
Per Firebird c'è questo: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Peccato che attualmente siano irraggiungibili sia le api che il tutorial.
Ecco, quello che non mi è mai piaciuto di Firebird è una certa confusione nella documentazione e soprattutto nelle metodologie di connessione con i vari linguaggi. Nelle release notes si parla di versione 2.5.x. Il link mancante è alle API 1.7. La feature list è della versione 1.6 :D
Al contrario uno dei punti di forza di PostgreSQL è proprio al documentazione.
Mantis-89
27-03-2010, 08:55
Mi sono spiegato male. E' utilizzabile gratuitamente per scopi commerciali a patto di rilasciare il codice sorgente a cui è linkata la libreria client e il connector sotto GPL.
E' vero che non necessariamente GPL significa gratuito, ma è altrettanto vero che linkare codice GPL in un software commerciale è un bel problema.
Qualche anno fa era rilasciato sotto forma di LGPL e non c'erano di questi problemi.
E allora il campo si restringe (a meno di trovare una libreria rilasciata in un altra licenza).
Inoltre è disponibile anche in versione embedded, eventualmente (non è il tuo caso, ma è giusto che tu lo sappia): quindi zero installazioni.
All'inizio avevo in mente un programma monoutente e avevo proprio guardato a questo ;)
Mantis: secondo me bisogna valutare bene anche come, da C#, ci si connette al DB.
In che senso?
Comunque inizio ad evere una certa preferenza per FireBird, me lo installo e lo provo intanto :)
E' vero che non necessariamente GPL significa gratuito, ma è altrettanto vero che linkare codice GPL in un software commerciale è un bel problema.
Qualche anno fa era rilasciato sotto forma di LGPL e non c'erano di questi problemi.
E allora il campo si restringe (a meno di trovare una libreria rilasciata in un altra licenza).
Inoltre è disponibile anche in versione embedded, eventualmente (non è il tuo caso, ma è giusto che tu lo sappia): quindi zero installazioni.
All'inizio avevo in mente un programma monoutente e avevo proprio guardato a questo ;)
Mantis: secondo me bisogna valutare bene anche come, da C#, ci si connette al DB.
In che senso?
Comunque inizio ad evere una certa preferenza per FireBird, me lo installo e lo provo intanto :)
cdimauro
27-03-2010, 08:59
Spiega un po' meglio... Intendi il lock a livello di tabella usato sulle MyISAM ?
Esatto, ma non solo con le MyISAM: è capitato sicuramente anche con NDS (se non ricordo male si chiama così l'engine usato per il cluster).
PostgreSQL ha addirittura licenza BSD ;)
Vabbé, c'è poca differenza. :D
Per Firebird c'è questo: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Peccato che attualmente siano irraggiungibili sia le api che il tutorial.
Strano. Magari c'è qualche problema di manutenzione.
Ecco, quello che non mi è mai piaciuto di Firebird è una certa confusione nella documentazione e soprattutto nelle metodologie di connessione con i vari linguaggi.
Mumble. Perché? La libreria di FireBird è sempre la stessa (interfaccia C-like).
Poi, eventualmente, ci sono wrapper per alcuni linguaggi che ne semplificano l'utilizzo e/o ne adattano l'accesso per essere conformi con le specifiche standard di connessione ai DB (qui mi riferisco a Python e PERL, in particolare).
Nelle release notes si parla di versione 2.5.x. Il link mancante è alle API 1.7. La feature list è della versione 1.6 :D
Ehm. Potresti riportare i link a questi documenti? Mi sono perso. :D
Al contrario uno dei punti di forza di PostgreSQL è proprio al documentazione.
Questo sicuramente: è più ben curata, non v'è dubbio. D'altra parte la comunità di PostgreSQL è ben più numerosa.
Esatto, ma non solo con le MyISAM: è capitato sicuramente anche con NDS (se non ricordo male si chiama così l'engine usato per il cluster).
PostgreSQL ha addirittura licenza BSD ;)
Vabbé, c'è poca differenza. :D
Per Firebird c'è questo: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Peccato che attualmente siano irraggiungibili sia le api che il tutorial.
Strano. Magari c'è qualche problema di manutenzione.
Ecco, quello che non mi è mai piaciuto di Firebird è una certa confusione nella documentazione e soprattutto nelle metodologie di connessione con i vari linguaggi.
Mumble. Perché? La libreria di FireBird è sempre la stessa (interfaccia C-like).
Poi, eventualmente, ci sono wrapper per alcuni linguaggi che ne semplificano l'utilizzo e/o ne adattano l'accesso per essere conformi con le specifiche standard di connessione ai DB (qui mi riferisco a Python e PERL, in particolare).
Nelle release notes si parla di versione 2.5.x. Il link mancante è alle API 1.7. La feature list è della versione 1.6 :D
Ehm. Potresti riportare i link a questi documenti? Mi sono perso. :D
Al contrario uno dei punti di forza di PostgreSQL è proprio al documentazione.
Questo sicuramente: è più ben curata, non v'è dubbio. D'altra parte la comunità di PostgreSQL è ben più numerosa.
cionci
27-03-2010, 09:14
Strano. Magari c'è qualche problema di manutenzione.
Il link è sempre quello sopra: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Prova clickare su API documentation (1.7), quando l'ultima release note (subito sotto) è per la versione 2.5.2. Poi clicka su "Feature List" e vengono presentate quelle della release 1.6 :)
Il link è sempre quello sopra: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Prova clickare su API documentation (1.7), quando l'ultima release note (subito sotto) è per la versione 2.5.2. Poi clicka su "Feature List" e vengono presentate quelle della release 1.6 :)
WarDuck
27-03-2010, 09:20
Tra i tre credo che quello che stia messo peggio a livello di supporto degli standard sia MySQL... l'ultima versione che avevo provato ignorava i CHECK.
cionci
27-03-2010, 09:27
E allora il campo si restringe (a meno di trovare una libreria rilasciata in un altra licenza).
Non è possibile che esista perché in ogni caso la client library di basso livello è comunque GPL e quindi non puoi rilassare la licenza.
In che senso?
Nel senso che non è detto che gli ADO.Net connector di tutti i tre siano fatti bene. Dovresti testarli un po'.
Non è possibile che esista perché in ogni caso la client library di basso livello è comunque GPL e quindi non puoi rilassare la licenza.
In che senso?
Nel senso che non è detto che gli ADO.Net connector di tutti i tre siano fatti bene. Dovresti testarli un po'.
Mantis-89
27-03-2010, 10:17
Ho capito, grazie a tutti. Voglio provare con FireBird :)
lupoxxx87
27-03-2010, 10:57
Tra i tre credo che quello che stia messo peggio a livello di supporto degli standard sia MySQL... l'ultima versione che avevo provato ignorava i CHECK.
mysql non ha mai supportato i check....
cmq..perchè stai a preoccuparti di database se devi lavorare su un programma mono utente ?
scriverti un parser non è meglio ?
mysql non ha mai supportato i check....
cmq..perchè stai a preoccuparti di database se devi lavorare su un programma mono utente ?
scriverti un parser non è meglio ?
WarDuck
27-03-2010, 11:25
mysql non ha mai supportato i check....
Appunto :D.
cmq..perchè stai a preoccuparti di database se devi lavorare su un programma mono utente ?
scriverti un parser non è meglio ?
Al massimo potrebbe usare XML dato che la maggior parte dei linguaggi di programmazione ha già gli strumenti per trattarlo.
Cmq:
[..]
Si non andrò a trattare una mole di dati enorme (credo verrà fuori qualcosa come 3 tabelle di sistema, 3-6 tabelle di dati con una velocità di crescita di 400 record al giorno) però mi serve un database relazionale che lavori in rete e in multi utenza (la concorrenza la gestirò a livello di applicazione)
Grazie
Un DB sicuramente risolve molti problemi. Gli strumenti già ci sono, usiamoli!!! :D
In ogni caso a mio modo di vedere è meglio spostare gran parte della logica nel DB stesso, compresa la gestione della concorrenza.
Appunto :D.
cmq..perchè stai a preoccuparti di database se devi lavorare su un programma mono utente ?
scriverti un parser non è meglio ?
Al massimo potrebbe usare XML dato che la maggior parte dei linguaggi di programmazione ha già gli strumenti per trattarlo.
Cmq:
[..]
Si non andrò a trattare una mole di dati enorme (credo verrà fuori qualcosa come 3 tabelle di sistema, 3-6 tabelle di dati con una velocità di crescita di 400 record al giorno) però mi serve un database relazionale che lavori in rete e in multi utenza (la concorrenza la gestirò a livello di applicazione)
Grazie
Un DB sicuramente risolve molti problemi. Gli strumenti già ci sono, usiamoli!!! :D
In ogni caso a mio modo di vedere è meglio spostare gran parte della logica nel DB stesso, compresa la gestione della concorrenza.
cionci
27-03-2010, 11:34
In ogni caso a mio modo di vedere è meglio spostare gran parte della logica nel DB stesso, compresa la gestione della concorrenza.
Su questo non posso fare altro che sottoscrivere... Con le transazioni la cosa diventa molto semplice. Tra l'altro sono tutti e tre ACID compliant.
Su questo non posso fare altro che sottoscrivere... Con le transazioni la cosa diventa molto semplice. Tra l'altro sono tutti e tre ACID compliant.
lupoxxx87
27-03-2010, 11:52
boh...sarà che a forza di programmare eeprom ho perso il punto di vista applicativo....
ma sono convinto che se un programma funzioni in locale, e sia monoutente, non abbia nè bisogno di un database, nè grossi problemi di concorrenza (a meno che non sia un multithread con presenza di più letture/scritture contemporanee..)
ma sono convinto che se un programma funzioni in locale, e sia monoutente, non abbia nè bisogno di un database, nè grossi problemi di concorrenza (a meno che non sia un multithread con presenza di più letture/scritture contemporanee..)
cionci
27-03-2010, 11:54
Scusa, ma dove l'ha scritto che è monutente ? Ha scritto che è a multiutenza, però voleva gestire la concorrenza da programma.
cdimauro
27-03-2010, 12:25
Il link è sempre quello sopra: http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
Prova clickare su API documentation (1.7), quando l'ultima release note (subito sotto) è per la versione 2.5.2. Poi clicka su "Feature List" e vengono presentate quelle della release 1.6 :)
OK, ho visto. Il dominio sembra scaduto: è per questo che i link non funzionano.
Effettivamente la feature list è ancora ferma alla vecchia 1.6.
Per quanto riguarda la 2.5.2, non ho trovato il link.
In ogni caso è evidente che la documentazione del provider .NET non sia aggiornata.:stordita:
Tra i tre credo che quello che stia messo peggio a livello di supporto degli standard sia MySQL... l'ultima versione che avevo provato ignorava i CHECK.
Esegue solo il parsing. E lo stesso fa con le foreign key. Nemmeno un warning.
Così se poi provi a usare queste caratteristiche e non funziona una mazza, diventi pazzo cercando di capire perché non vanno. :muro: :muro: :muro:
Ho capito, grazie a tutti. Voglio provare con FireBird :)
Eccellente, Smithers. :cool:
mysql non ha mai supportato i check....
cmq..perchè stai a preoccuparti di database se devi lavorare su un programma mono utente ?
scriverti un parser non è meglio ?
Guarda, anche quando scrivo un'applicazione monoutente, preferisco nettamente FireBird anche a soluzioni più semplici come SQLite.
Il motivo è duplice: prima di tutto in versione embedded non occupa molto spazio (4MB ormai da un decennio buono non sono NULLA in termini di spazio).
Secondo, e più importante, quando hai assaporato l'uso di trigger, stored procedure (e ci metterei anche i domain di FireBird), ecc., è difficile farne a meno.
Poi FireBird per trigger e stored procedure a mio avviso per il suo PL/SQL ha una sintassi che non teme rivali: semplice e potente.
Realizzare cicli sulle query è una goduria immensa. :sbav:
Su questo non posso fare altro che sottoscrivere... Con le transazioni la cosa diventa molto semplice. Tra l'altro sono tutti e tre ACID compliant.
MySQL solo con InnoDB e NDS (non ricordo se BDB lo supporta). E le prestazioni sceeeeeeeeeeeeendono molto.
Prova clickare su API documentation (1.7), quando l'ultima release note (subito sotto) è per la versione 2.5.2. Poi clicka su "Feature List" e vengono presentate quelle della release 1.6 :)
OK, ho visto. Il dominio sembra scaduto: è per questo che i link non funzionano.
Effettivamente la feature list è ancora ferma alla vecchia 1.6.
Per quanto riguarda la 2.5.2, non ho trovato il link.
In ogni caso è evidente che la documentazione del provider .NET non sia aggiornata.:stordita:
Tra i tre credo che quello che stia messo peggio a livello di supporto degli standard sia MySQL... l'ultima versione che avevo provato ignorava i CHECK.
Esegue solo il parsing. E lo stesso fa con le foreign key. Nemmeno un warning.
Così se poi provi a usare queste caratteristiche e non funziona una mazza, diventi pazzo cercando di capire perché non vanno. :muro: :muro: :muro:
Ho capito, grazie a tutti. Voglio provare con FireBird :)
Eccellente, Smithers. :cool:
mysql non ha mai supportato i check....
cmq..perchè stai a preoccuparti di database se devi lavorare su un programma mono utente ?
scriverti un parser non è meglio ?
Guarda, anche quando scrivo un'applicazione monoutente, preferisco nettamente FireBird anche a soluzioni più semplici come SQLite.
Il motivo è duplice: prima di tutto in versione embedded non occupa molto spazio (4MB ormai da un decennio buono non sono NULLA in termini di spazio).
Secondo, e più importante, quando hai assaporato l'uso di trigger, stored procedure (e ci metterei anche i domain di FireBird), ecc., è difficile farne a meno.
Poi FireBird per trigger e stored procedure a mio avviso per il suo PL/SQL ha una sintassi che non teme rivali: semplice e potente.
Realizzare cicli sulle query è una goduria immensa. :sbav:
Su questo non posso fare altro che sottoscrivere... Con le transazioni la cosa diventa molto semplice. Tra l'altro sono tutti e tre ACID compliant.
MySQL solo con InnoDB e NDS (non ricordo se BDB lo supporta). E le prestazioni sceeeeeeeeeeeeendono molto.
Mantis-89
27-03-2010, 12:45
All'inizio volevo realizzare un programma monoutente poi ho cambiato idea e ho deciso di fare le cose fatte bene per cui sono passato alla multiutenza.
Io vorrei fare inoltre che quando un utente "apre" in modifica un record gli altri possano "aprirlo" solo in sola lettura. Non credo che questo sia possibile se non utilizzando qualche comando specifico del database o sbaglio? Perchè vorrei fare qualcosa che non dipenda troppo dal database in uso (se domani FireBird non mi piace più o non piace al cliente, se avrà successo, vorrei poter cambiare solo il .Net adapter, la stringa di connessione e via). Per questo ho pensato ad una cosa a livello applicazione :D
Io vorrei fare inoltre che quando un utente "apre" in modifica un record gli altri possano "aprirlo" solo in sola lettura. Non credo che questo sia possibile se non utilizzando qualche comando specifico del database o sbaglio? Perchè vorrei fare qualcosa che non dipenda troppo dal database in uso (se domani FireBird non mi piace più o non piace al cliente, se avrà successo, vorrei poter cambiare solo il .Net adapter, la stringa di connessione e via). Per questo ho pensato ad una cosa a livello applicazione :D
cdimauro
27-03-2010, 14:12
Fare quello che chiedi richiede l'uso di LOCK sul singolo record, ed è una caratteristica che:
- non tutti i database hanno;
- fa diminuire sensibilmente le prestazioni;
- può provocare deadlock (auch!).
Per cui ovviamente te lo sconsiglio fortemente.
FireBird è multitransazionale e ottimistico, come dicevo qualche messaggio fa. Questo significa che ogni cliente che è connesso che ha letto quel determinato record, ne conserva quella particolare versione, anche se nel frattempo un client l'ha modificato (è soltanto il cliente che ha fatto la modifica che la "vede").
Ovviamente più client possono modificare lo stesso record e avere visione della sola modifica che hanno apportato loro.
E' nel momento in cui vengono eseguiti i commit delle rispettive transazioni che "i nodi vengono al pettine". Soltanto il primo per cui andrà in porto il commit vedrà il database modificato in accordo.
Per tutti gli altri verrà sollevata un'opportuna eccezione, e a questo punto la "palla" passerà nuovamente al client, che deciderà se effettuare il rollback e provare a rieseguire la transazione, oppure andare a vedere cos'è che è cambiato ed eseguire altre operazioni, o altro ancora.
Inutile dire che un modello del genere è pensato per scalare molto bene prestazionalmente, proprio perché non si fa uso di lock. ;)
- non tutti i database hanno;
- fa diminuire sensibilmente le prestazioni;
- può provocare deadlock (auch!).
Per cui ovviamente te lo sconsiglio fortemente.
FireBird è multitransazionale e ottimistico, come dicevo qualche messaggio fa. Questo significa che ogni cliente che è connesso che ha letto quel determinato record, ne conserva quella particolare versione, anche se nel frattempo un client l'ha modificato (è soltanto il cliente che ha fatto la modifica che la "vede").
Ovviamente più client possono modificare lo stesso record e avere visione della sola modifica che hanno apportato loro.
E' nel momento in cui vengono eseguiti i commit delle rispettive transazioni che "i nodi vengono al pettine". Soltanto il primo per cui andrà in porto il commit vedrà il database modificato in accordo.
Per tutti gli altri verrà sollevata un'opportuna eccezione, e a questo punto la "palla" passerà nuovamente al client, che deciderà se effettuare il rollback e provare a rieseguire la transazione, oppure andare a vedere cos'è che è cambiato ed eseguire altre operazioni, o altro ancora.
Inutile dire che un modello del genere è pensato per scalare molto bene prestazionalmente, proprio perché non si fa uso di lock. ;)
Mantis-89
27-03-2010, 14:35
Io vorrei tenere traccia in una tabella dei record in uso di ogni altra tabella (con nometabella e id del record) per cui quando un utente "apre" in modifica in record il record viene inserito nella tabella (anzi viene aperto se riesce ad inserirlo in quanto nome tabella + id record sarà univoco) e quando l'utente salva il record aperto allora viene esguito l'update e il record nella tabelle di lock eliminato. Si tratta di una gestione semplice che va gestita correttamete a livello dell'applicazione per farla funzionare.
cionci
27-03-2010, 14:44
Esegue solo il parsing. E lo stesso fa con le foreign key. Nemmeno un warning.
Le foreign key vanno, almeno su InnoDB.
MySQL solo con InnoDB e NDS (non ricordo se BDB lo supporta). E le prestazioni sceeeeeeeeeeeeendono molto.
Ormai InnoDB è il tipo di tabella di default ;)
Le foreign key vanno, almeno su InnoDB.
MySQL solo con InnoDB e NDS (non ricordo se BDB lo supporta). E le prestazioni sceeeeeeeeeeeeendono molto.
Ormai InnoDB è il tipo di tabella di default ;)
cionci
27-03-2010, 14:51
Come già detto da Cesare, la cosa migliore è lasciare lavorare le transazioni.
Quello che vuoi fare ha senso, ma ci sono comunque problemi di concorrenza che devi risolvere in ogni caso con le transazioni.
PS: ti conviene lasciare anche l'id utente nella tabella ed il time stamp...
PPS: Cosa succede se un client si chiude prima di togliere il lock :fiufiu:
PPPS: I lock sono solo per la scrittura o sono per lettura e scrittura ?
Quello che vuoi fare ha senso, ma ci sono comunque problemi di concorrenza che devi risolvere in ogni caso con le transazioni.
PS: ti conviene lasciare anche l'id utente nella tabella ed il time stamp...
PPS: Cosa succede se un client si chiude prima di togliere il lock :fiufiu:
PPPS: I lock sono solo per la scrittura o sono per lettura e scrittura ?
gugoXX
27-03-2010, 15:11
All'inizio volevo realizzare un programma monoutente poi ho cambiato idea e ho deciso di fare le cose fatte bene per cui sono passato alla multiutenza.
Io vorrei fare inoltre che quando un utente "apre" in modifica un record gli altri possano "aprirlo" solo in sola lettura. Non credo che questo sia possibile se non utilizzando qualche comando specifico del database o sbaglio? Perchè vorrei fare qualcosa che non dipenda troppo dal database in uso (se domani FireBird non mi piace più o non piace al cliente, se avrà successo, vorrei poter cambiare solo il .Net adapter, la stringa di connessione e via). Per questo ho pensato ad una cosa a livello applicazione :D
Se questi 4GB non ti sono proprio stretti (e davvero faccio fatica a credere che lo siano), e' una delle modalita' transazionali di SqlServer, peraltro comandabile in fase di apertura della transazione, oppure di default nella connessione.
La prima transazione che opera in scrittura su un record, forzera' il lock in scrittura per tutte le altre.
Se la scrittura e' prevista su piu' tabelle, per evitare deadlock ci sono diverse alternative.
Esposto anche su LINQ to SQL e sull'entity framework.
E' un parametro solo. Se cambi DB cambi il parametro...
Il discorso del aborrire una versione castrata non lo condivido.
Se a un Ferrari castri 50 cavalli, hai sempre un motore migliore di una Panda non castrata.
SE davvero sei vicino al limite dei 4GB, ti consiglierei anche Oracle Express senza paura di proporre un overkill, con licenza gratis completamente ridistribuibile anche per applicazioni commerciali (a differenza di MySql).
Io vorrei fare inoltre che quando un utente "apre" in modifica un record gli altri possano "aprirlo" solo in sola lettura. Non credo che questo sia possibile se non utilizzando qualche comando specifico del database o sbaglio? Perchè vorrei fare qualcosa che non dipenda troppo dal database in uso (se domani FireBird non mi piace più o non piace al cliente, se avrà successo, vorrei poter cambiare solo il .Net adapter, la stringa di connessione e via). Per questo ho pensato ad una cosa a livello applicazione :D
Se questi 4GB non ti sono proprio stretti (e davvero faccio fatica a credere che lo siano), e' una delle modalita' transazionali di SqlServer, peraltro comandabile in fase di apertura della transazione, oppure di default nella connessione.
La prima transazione che opera in scrittura su un record, forzera' il lock in scrittura per tutte le altre.
Se la scrittura e' prevista su piu' tabelle, per evitare deadlock ci sono diverse alternative.
Esposto anche su LINQ to SQL e sull'entity framework.
E' un parametro solo. Se cambi DB cambi il parametro...
Il discorso del aborrire una versione castrata non lo condivido.
Se a un Ferrari castri 50 cavalli, hai sempre un motore migliore di una Panda non castrata.
SE davvero sei vicino al limite dei 4GB, ti consiglierei anche Oracle Express senza paura di proporre un overkill, con licenza gratis completamente ridistribuibile anche per applicazioni commerciali (a differenza di MySql).
Johnn
27-03-2010, 17:53
Secondo me invece si deve fare parecchia attenzione all'utilizzo di Oracle Express Edition.
I limiti principali sono:
1 CPU
RAM: 1 Gb
portata max Database: 4Gb
Per tutte le limitazioni:
http://www.oracle.com/lang/it/database/product_editions.html
Se deve essere usata a scopi didattici o per applicazioni casalinghe o comunque senza possibilità di superare i limiti imposti, va benissimo; ma iniziare con un'applicazione che magari rientra nei limiti, ma in futuro potrebbe richiedere più di una CPU, per esempio, significa fare il gioco di Oracle (legittimo fare così da parte loro): io ti faccio assaggiare la Ferrari in città. Appena vuoi andare in autostrada, difficilmente ritornerai al concessionario per prendere la Panda (cioè migrare il db proprio sul più bello) e quindi sganci i $$$.
I limiti principali sono:
1 CPU
RAM: 1 Gb
portata max Database: 4Gb
Per tutte le limitazioni:
http://www.oracle.com/lang/it/database/product_editions.html
Se deve essere usata a scopi didattici o per applicazioni casalinghe o comunque senza possibilità di superare i limiti imposti, va benissimo; ma iniziare con un'applicazione che magari rientra nei limiti, ma in futuro potrebbe richiedere più di una CPU, per esempio, significa fare il gioco di Oracle (legittimo fare così da parte loro): io ti faccio assaggiare la Ferrari in città. Appena vuoi andare in autostrada, difficilmente ritornerai al concessionario per prendere la Panda (cioè migrare il db proprio sul più bello) e quindi sganci i $$$.
gugoXX
27-03-2010, 18:24
Secondo me invece si deve fare parecchia attenzione all'utilizzo di Oracle Express Edition.
I limiti principali sono:
1 CPU
RAM: 1 Gb
portata max Database: 4Gb
Per tutte le limitazioni:
http://www.oracle.com/lang/it/database/product_editions.html
Se deve essere usata a scopi didattici o per applicazioni casalinghe o comunque senza possibilità di superare i limiti imposti, va benissimo; ma iniziare con un'applicazione che magari rientra nei limiti, ma in futuro potrebbe richiedere più di una CPU, per esempio, significa fare il gioco di Oracle (legittimo fare così da parte loro): io ti faccio assaggiare la Ferrari in città. Appena vuoi andare in autostrada, difficilmente ritornerai al concessionario per prendere la Panda (cioè migrare il db proprio sul più bello) e quindi sganci i $$$.
Puoi stare tranquillo. Per riempire 4GB di dati e per avere bisogno di piu' un 1GB di RAM per le query, ci vuole un applicazione ben piu' che casalinga.
I limiti principali sono:
1 CPU
RAM: 1 Gb
portata max Database: 4Gb
Per tutte le limitazioni:
http://www.oracle.com/lang/it/database/product_editions.html
Se deve essere usata a scopi didattici o per applicazioni casalinghe o comunque senza possibilità di superare i limiti imposti, va benissimo; ma iniziare con un'applicazione che magari rientra nei limiti, ma in futuro potrebbe richiedere più di una CPU, per esempio, significa fare il gioco di Oracle (legittimo fare così da parte loro): io ti faccio assaggiare la Ferrari in città. Appena vuoi andare in autostrada, difficilmente ritornerai al concessionario per prendere la Panda (cioè migrare il db proprio sul più bello) e quindi sganci i $$$.
Puoi stare tranquillo. Per riempire 4GB di dati e per avere bisogno di piu' un 1GB di RAM per le query, ci vuole un applicazione ben piu' che casalinga.
cdimauro
27-03-2010, 18:26
Io vorrei tenere traccia in una tabella dei record in uso di ogni altra tabella (con nometabella e id del record) per cui quando un utente "apre" in modifica in record il record viene inserito nella tabella (anzi viene aperto se riesce ad inserirlo in quanto nome tabella + id record sarà univoco) e quando l'utente salva il record aperto allora viene esguito l'update e il record nella tabelle di lock eliminato. Si tratta di una gestione semplice che va gestita correttamete a livello dell'applicazione per farla funzionare.
:eek: Lascia perdere. Mi piange il cuore a vedere un database trattato così. :cry:
Le foreign key vanno, almeno su InnoDB.
Sì, chiaro. Mi riferivo ai casi in cui, pur eseguendo il parsing, non sono applicate e... non lo sai! :muro:
Ormai InnoDB è il tipo di tabella di default ;)
Hum. Mi sembrava che la politica fosse cambiata con l'acquisizione di InnoDB da parte di Oracle.
In ogni caso si tratta di un'ottima notizia. :)
:eek: Lascia perdere. Mi piange il cuore a vedere un database trattato così. :cry:
Le foreign key vanno, almeno su InnoDB.
Sì, chiaro. Mi riferivo ai casi in cui, pur eseguendo il parsing, non sono applicate e... non lo sai! :muro:
Ormai InnoDB è il tipo di tabella di default ;)
Hum. Mi sembrava che la politica fosse cambiata con l'acquisizione di InnoDB da parte di Oracle.
In ogni caso si tratta di un'ottima notizia. :)
Mantis-89
27-03-2010, 18:30
Come già detto da Cesare, la cosa migliore è lasciare lavorare le transazioni.
Quello che vuoi fare ha senso, ma ci sono comunque problemi di concorrenza che devi risolvere in ogni caso con le transazioni.
PS: ti conviene lasciare anche l'id utente nella tabella ed il time stamp...
PPS: Cosa succede se un client si chiude prima di togliere il lock :fiufiu:
PPPS: I lock sono solo per la scrittura o sono per lettura e scrittura ?
ogni client aggiorna lo stato della propria connessione ogni tot (datetime sulla tabella che tiene conto delle connessioni utente). quando un utente deve esguire un lock e il record è loccato viene fatto il controllo che il client che tiene in lock il record non sia morto.
Ho capito il discorso delle transazioni (che utilizzerò) però io voglio che finchè l'utente tiene aperto il record (anche solo per guardarlo) questo non sia disponibile. Se l'utente tiene il recod apero per mezzora perchè si dimentica gli altri utenti vedranno che il record è in uso dall'utente x.
Quello che vuoi fare ha senso, ma ci sono comunque problemi di concorrenza che devi risolvere in ogni caso con le transazioni.
PS: ti conviene lasciare anche l'id utente nella tabella ed il time stamp...
PPS: Cosa succede se un client si chiude prima di togliere il lock :fiufiu:
PPPS: I lock sono solo per la scrittura o sono per lettura e scrittura ?
ogni client aggiorna lo stato della propria connessione ogni tot (datetime sulla tabella che tiene conto delle connessioni utente). quando un utente deve esguire un lock e il record è loccato viene fatto il controllo che il client che tiene in lock il record non sia morto.
Ho capito il discorso delle transazioni (che utilizzerò) però io voglio che finchè l'utente tiene aperto il record (anche solo per guardarlo) questo non sia disponibile. Se l'utente tiene il recod apero per mezzora perchè si dimentica gli altri utenti vedranno che il record è in uso dall'utente x.
cionci
27-03-2010, 18:32
Se l'utente tiene il recod apero per mezzora perchè si dimentica gli altri utenti vedranno che il record è in uso dall'utente x.
E quindi come si comporteranno gli altri se dovranno usare quei dati ?
E quindi come si comporteranno gli altri se dovranno usare quei dati ?
Mantis-89
28-03-2010, 10:35
Aspettano che l'utente lo chiuda o lo aprono in sola lettura.
cionci
28-03-2010, 10:36
Aspettano che l'utente lo chiuda o lo aprono in sola lettura.
Per quel record ok, ma se un utente deve usare i dati contenuti in quella tabella per una query... La query è invalidata se contiene uno dei record bloccati ?
Per quel record ok, ma se un utente deve usare i dati contenuti in quella tabella per una query... La query è invalidata se contiene uno dei record bloccati ?
Mantis-89
28-03-2010, 10:40
:eek: Lascia perdere. Mi piange il cuore a vedere un database trattato così. :cry:
Tranquillo non lo voglio mica fare per ogni update ;)
Come detto voglio solo impedire ad un utente di andare in modifica di un record quando è già in uso.
Tranquillo non lo voglio mica fare per ogni update ;)
Come detto voglio solo impedire ad un utente di andare in modifica di un record quando è già in uso.
Mantis-89
28-03-2010, 10:43
Per quel record ok, ma se un utente deve usare i dati contenuti in quella tabella per una query... La query è invalidata se contiene uno dei record bloccati ?
No
No
cionci
28-03-2010, 10:47
Ok, quindi vuoi bloccare solo modifica contemporanea.
Imho potresti gestire bene con i trigger l'effettiva cancellazione dei lock in caso di timeout.
Imho potresti gestire bene con i trigger l'effettiva cancellazione dei lock in caso di timeout.
gugoXX
28-03-2010, 11:03
Detta cosi', e' la gestione normale, proprio normalissima, di un database (uin database vero pero', gli altri non garantisco).
Apri una transazione, modifichi un record, tieni aperta la transazione.
Tutti gli altri potranno entrare in lettura su tale record, e aspetteranno invece se dovessero tentare una scrittura.
Fino a che la transazione non restera' aperta.
Apri una transazione, modifichi un record, tieni aperta la transazione.
Tutti gli altri potranno entrare in lettura su tale record, e aspetteranno invece se dovessero tentare una scrittura.
Fino a che la transazione non restera' aperta.
Mantis-89
28-03-2010, 11:12
Ok, quindi vuoi bloccare solo modifica contemporanea.
Imho potresti gestire bene con i trigger l'effettiva cancellazione dei lock in caso di timeout.
In che senso? Fare il controllo sullo stato della connessione dell'utente che lo tiene in lock ed eventualemnte sbloccarlo in caso direttamente da Trigger?
Beh si può fare, si tratta sempre di decidere quanto codice lasciare sul database e quanto sull'applicazione. Di sicuro con i trigger è più veloce (e magari anche più sicuro) però ogni database avrebbe un trigger scritto diversamente giusto?
Imho potresti gestire bene con i trigger l'effettiva cancellazione dei lock in caso di timeout.
In che senso? Fare il controllo sullo stato della connessione dell'utente che lo tiene in lock ed eventualemnte sbloccarlo in caso direttamente da Trigger?
Beh si può fare, si tratta sempre di decidere quanto codice lasciare sul database e quanto sull'applicazione. Di sicuro con i trigger è più veloce (e magari anche più sicuro) però ogni database avrebbe un trigger scritto diversamente giusto?
Mantis-89
28-03-2010, 11:14
Detta cosi', e' la gestione normale, proprio normalissima, di un database (uin database vero pero', gli altri non garantisco).
Apri una transazione, modifichi un record, tieni aperta la transazione.
Tutti gli altri potranno entrare in lettura su tale record, e aspetteranno invece se dovessero tentare una scrittura.
Fino a che la transazione non restera' aperta.
Il record lo modifico solo prima di chiudere la transazione l'utente lavoro sulla copia in locale. E in questo modo potrei avere dei dead lock.
Apri una transazione, modifichi un record, tieni aperta la transazione.
Tutti gli altri potranno entrare in lettura su tale record, e aspetteranno invece se dovessero tentare una scrittura.
Fino a che la transazione non restera' aperta.
Il record lo modifico solo prima di chiudere la transazione l'utente lavoro sulla copia in locale. E in questo modo potrei avere dei dead lock.
gugoXX
28-03-2010, 11:20
Il record lo modifico solo prima di chiudere la transazione l'utente lavoro sulla copia in locale. E in questo modo potrei avere dei dead lock.
Se costruisci la tua gestione dei lock, che dovesse replicare il comportamento di cui sopra, avrai tanti deadlock quanti ne avresti avuti se la gestione dei lock l'avessi lasciata al solo database.
Inoltre pensa, p.es. se l'applicazione client si schianta (terminologia tecnica informatica, soprattutto quando c'e' un database coinvolto).
Nel caso di gestione demandata al database, la transazione viene forzata chiusa con rollback, e il record e' di nuovo libero.
Nel caso di gestione tua invece devi prevedere e gestire questo evento, altrimenti nessuno potra' piu' accedere al record.
Se costruisci la tua gestione dei lock, che dovesse replicare il comportamento di cui sopra, avrai tanti deadlock quanti ne avresti avuti se la gestione dei lock l'avessi lasciata al solo database.
Inoltre pensa, p.es. se l'applicazione client si schianta (terminologia tecnica informatica, soprattutto quando c'e' un database coinvolto).
Nel caso di gestione demandata al database, la transazione viene forzata chiusa con rollback, e il record e' di nuovo libero.
Nel caso di gestione tua invece devi prevedere e gestire questo evento, altrimenti nessuno potra' piu' accedere al record.
Mantis-89
28-03-2010, 11:37
Come ho detto:
-Il lock si applica solo per aprire in modifica il record e non influisce il funzionamento di qualsiasi altra query
-Se il lock fallisce controllo che che la connessione dell'utente che sta eseguendo il lock non sia "morta" e in tal caso rimuovo tutti i lock per quell'utente (dall'applicazione o da trigger come mi suggeriva cionci)
So che forse non è la soluzione migliore però intanto voglio provare a seguire questa strada che come tutte le altre possibili ha i suoi pro e i suoi contro e le sue limitazioni.
-Il lock si applica solo per aprire in modifica il record e non influisce il funzionamento di qualsiasi altra query
-Se il lock fallisce controllo che che la connessione dell'utente che sta eseguendo il lock non sia "morta" e in tal caso rimuovo tutti i lock per quell'utente (dall'applicazione o da trigger come mi suggeriva cionci)
So che forse non è la soluzione migliore però intanto voglio provare a seguire questa strada che come tutte le altre possibili ha i suoi pro e i suoi contro e le sue limitazioni.
Mantis-89
28-03-2010, 11:42
.....ma FireBird non supporta le colonne autoincrementanti...? :confused:
cionci
28-03-2010, 11:49
In che senso? Fare il controllo sullo stato della connessione dell'utente che lo tiene in lock ed eventualemnte sbloccarlo in caso direttamente da Trigger?
Beh si può fare, si tratta sempre di decidere quanto codice lasciare sul database e quanto sull'applicazione. Di sicuro con i trigger è più veloce (e magari anche più sicuro) però ogni database avrebbe un trigger scritto diversamente giusto?
Esattamente. Ad esempio potresti mettere un trigger sulla rimozione dell'utente dalla lista degli utenti loggati. Se viene rimosso allora tutti i lock vengono rimossi automaticamente.
Per la rimozione di un utente in timeout puoi fare così: fai in modo che tutti gli utenti debbano fare un UPDATE del timestamp nella tabella degli utenti loggati ogni tot secondi (ad esempio 60 secondi).
Metti un trigger su UPDATE e su INSERT con relativa stored procedure che elimina tutti gli utenti il cui timestamp è più vecchio di 70 secondi. Così automaticamente lanci la rimozione dei lock di quell'utente.
Beh si può fare, si tratta sempre di decidere quanto codice lasciare sul database e quanto sull'applicazione. Di sicuro con i trigger è più veloce (e magari anche più sicuro) però ogni database avrebbe un trigger scritto diversamente giusto?
Esattamente. Ad esempio potresti mettere un trigger sulla rimozione dell'utente dalla lista degli utenti loggati. Se viene rimosso allora tutti i lock vengono rimossi automaticamente.
Per la rimozione di un utente in timeout puoi fare così: fai in modo che tutti gli utenti debbano fare un UPDATE del timestamp nella tabella degli utenti loggati ogni tot secondi (ad esempio 60 secondi).
Metti un trigger su UPDATE e su INSERT con relativa stored procedure che elimina tutti gli utenti il cui timestamp è più vecchio di 70 secondi. Così automaticamente lanci la rimozione dei lock di quell'utente.
Mantis-89
28-03-2010, 11:54
E' praticamente come l'avevo pensato (anche se vorrei che i tempo dopo cui un client è considerato morto sia almeno 2,5 volte il tempo di aggiornamento). Potrei lavorare sui trigger di inserimento della tabella delle connessioni utente e quella dei record in lock.
A lavoro quando ho parlato di un timer per gestire gli utenti connessi mi hannno guardato male tu che ne dici invece?
A lavoro quando ho parlato di un timer per gestire gli utenti connessi mi hannno guardato male tu che ne dici invece?
cionci
28-03-2010, 11:59
A lavoro quando ho parlato di un timer per gestire gli utenti connessi mi hannno guardato male tu che ne dici invece?
In che senso ?
In che senso ?
Mantis-89
28-03-2010, 12:23
Per fare l'update dovrò avere un timer, mi hanno detto che porta via troppe risorse e che non dovrei usarlo.
cionci
28-03-2010, 12:31
Per fare l'update dovrò avere un timer, mi hanno detto che porta via troppe risorse e che non dovrei usarlo.
L'update di cosa ?
L'update di cosa ?
Mantis-89
28-03-2010, 12:45
fai in modo che tutti gli utenti debbano fare un UPDATE del timestamp nella tabella degli utenti loggati ogni tot secondi (ad esempio 60 secondi).
:)
:)
cionci
28-03-2010, 13:07
Non mi sembra che un thread che si sveglia ogni 60 secondi ed effettua una query sia un'operazione costosa. Anzi...
Chiedigli meglio le motivazioni.
Chiedigli meglio le motivazioni.
Mantis-89
28-03-2010, 13:30
E' quello che ho pensato anche io... proverò a chiedere meglio.
Grazie comunque.
PS: Ora sto provando PostgreSQL e mi ha colpito positivamente
Grazie comunque.
PS: Ora sto provando PostgreSQL e mi ha colpito positivamente
cdimauro
28-03-2010, 17:49
.....ma FireBird non supporta le colonne autoincrementanti...? :confused:
No, e uno dei motivi è proprio quello di evitare il lock della tabella a cui sono legati. :D
Si usano i generatori o sequenze (http://www.firebirdsql.org/manual/generatorguide.html) (quest'ultimo è il termine usato nello standard SQL-9x e SQL-2003) che ti permettono, tra l'altro, di avere un controllo più fine.
No, e uno dei motivi è proprio quello di evitare il lock della tabella a cui sono legati. :D
Si usano i generatori o sequenze (http://www.firebirdsql.org/manual/generatorguide.html) (quest'ultimo è il termine usato nello standard SQL-9x e SQL-2003) che ti permettono, tra l'altro, di avere un controllo più fine.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.