Newsgroup: it.comp.lang.delphi
Titolo: Quale database

Ciao a tutti,
una domanda da principiante:
dovrei sviluppare un applicativo simil-gestionale , molto semplice e sono 
indeciso se utilizzare un database firebird o mysql.
Quale dei due mi da più garanzia di stabilità e funzionamento nel tempo?
La velocità non è la priorità.
Cosa mi consigliate?
Grazie mille 

 nel tempo?
i backup.
Ale

 ha scritto nel messaggio 
news:4cee78ef$0$6819$5fc...@news.tiscali.it...

Sono conscio dell'importanza dei backup, ma se un baco del motore del 
database poi mi blocca il lavoro del cliente, che me ne faccio di un bel 
backup?
Chiedo semplicemente a chi ha più esperienza di me se è più affidabile MySQL 
o Firebird... 

 più affidabile MySQL o Firebird...
considerato il numero di anni che i prodotti che hai menzionato sono in
circolazione, escludo che ci siano bachi clamorosi che possano portare
a blocchi del database o corruzione degli archivi.
Di bachi realmente pericolosi ce ne sono solo due, secondo me: il
programmatore, da un lato, e l'utonto, dall'altra :)
Ale

 i backup.
questi sconosciuti :)
Dai tempi dei nastri da 6250 ad oggi, non e' cambiato nulla : i backup la  
gente non li fa'.
-- 
=============================================================
Alberto Rubinelli - Fondazione "Museo del computer"
Via Costantino Perazzi 22 - 28100 NOVARA - ITALY
Tel 0321 1856032   Fax 0321 391769   BBS 0321 392320
Mail: 
alb...@oldcomputers.de
Sito internet : 
http://www.museodelcomputer.org
=============================================================

 indeciso se utilizzare un database firebird o mysql.
Io ti do un consiglio trasversale : non sviluppare un'applicazione  
basandoti sul database, se vuoi fare un bel lavoro, falla multidatabase.
Nel mio gestionale ad esempio ho un componente che e' il database che  
utilizzo, ma in realta' esso e' formato internamente dai componenti per  
gestire diversi tipi di database e dalle procedure per gestire la cosa.
Alla fine e' quasi tutto trasparente, c'e' una minima perdita di  
prestazioni, certo, ma puoi cambiare database quasi dall'oggi al domani.
Visto che inizi da zero, lavora per layer, e cerca di non perdere di vista  
la struttura quando sarai costretto a fare personalizzazioni selvagge per  
i clienti rompiscatole :)


 backup la  gente non li fa'.
e quando succede qualcosa, è sempre la stessa storia: "io" (utente)
"non ho fatto nulla" (sottinteso: la colpa è del tuo programma (quindi
del programmatore) e il problema me lo sistemi aggratis). :)))
Ah, se solo gli utenti si fossero evoluti 1/10mo di quanto si è evoluta
la tecnologia.. :))
Ale

 del programmatore) e il problema me lo sistemi aggratis). :)))
e' la stessa storia dell'ups ... non si compra se non dopo.
Ed il cliente : "ma che c***o di programma e' il vostro, che basta che va  
via la corrente ed io perdo i dati e deve uscire un tecnico? e' normale  
che va via la corrente" .
Quando i backup si facevano con i padelloni ed ognuno costava (agli inizi)  
anche 700.000 lire (del 1984, non di oggi) capisco anche che ci fosse una  
certa diffidenza ... ma oggi che avere un backup costa veramente poco ....
Oddio, c'e' anche qualcuno sfigato poi ... un mio cliente, faceva  
regolarmente il backup e riponeva le cassette (una per giorno settimana)  
appoggiate sopra il server : e' entrato un fulmine, ha perforato il  
gruppo, ha colpito il server, che ha preso fuoco : sono bruciati server e  
cassette sopra :(
Ciao.Alberto.


 cassette sopra :(
.. e anche se non fossero bruciate sarebbero comunque state inservibili,
perchè mai controllate nemmeno una volta :((
Ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 perchè mai controllate nemmeno una volta :((
 
no, beh, quello no, terminato il backup, veniva fatta la verifica di  
quanto salvato sul nastro, ed i nastri ruotavano settimanalmente, quindi  
il dato e' buono ... almeno quello :)


..io i nastri non li voglio piu' vedere.
Preferisco unita' esterne sulle quali VEDI i maledetti file.
Tornando al db, ribadisco che c'e' sempre stata molta confusione sulla
licenza d'uso di MySql.
A

 settimana) appoggiate sopra il server
che intelligentone sto tizio.. sarà più di 20 anni che vedo in vendita
cassaforti ignifughe specifiche per i supporti di backup. Ci sarà un
motivo, no? :))
Ale

 ..io i nastri non li voglio piu' vedere.
dai, hanno un fascino retrň niente male ;))
Ale

 motivo, no? :))
Si, vendere le cassaforti 

 Si, vendere le cassaforti
ahahah.. ah si, in effetti è una spesa inutile.. fino al primo incendio
;))
Ale

 i clienti rompiscatole :)
Finalmente una risposta seria.
Grazie mille 

 procedure per gestire la cosa.  
e con le query come fai? ogni database ha il suo dialetto sql.. e certe
cose in alcuni database non esistono proprio (ad esempio i trigger).
Ale

> dai, hanno un fascino retrò niente male ;))
..nel senso che ti arrivano nel "retro"? :-D
A.

 basandoti sul database, se vuoi fare un bel lavoro, falla multidatabase.
MDA?
A.

 Cosa mi consigliate?
Nei termini in cui hai posto la domanda, non esiste una risposta valida 
o che sia giusta in senso assoluto.
Posto che entrambi andrebbero benissimo per le tue esigenze, senza 
particolari differenze, dai un'occhiata ai rispettivi siti ufficiali e, 
in base alle caratteristiche, fai liberamente la tua scelta personale.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 ;))
Pure dopo
Se guardi bene le caratteristiche delle cassaforti, armadi, ed altre 
cassette ignifughe, sono tutte caratterizzate dal resistere un certo tempo 
ad una certa temperatura massima, assicurando un innalzamento della 
temperatura interna al di sotto di un certo valore
Bon, il problema sta nel fatto che quel 'certo tempo' e' di solito dai 30 ai 
90 minuti, e la temperatura e' tra gli 800 ed i 1000 gradi
Quando si bruciasse tutto davero, pensi davvero che in mezz'ora si possa 
risolvere tutto?
Personalmente non credo
Avere la cassettina ignifuga e' sicuramente meglio di niente, ma ben lontana 
dal dare la sicurezza che si meriterebbero le copie di backup
Una soluzione migliore consiste nel semplice 'portale distanti dal pc'
Funziona senz'altro meglio, il problema e' che costa niente, e quindi sembra 
non essere all'altezza di altre soluzioni piu' costose
Ciao
RobertoA

 risolvere tutto?  
si arriva anche a valori di temperatura e tempi più alti.. dipende da
quanto si è disposti a spendere. Non necessariamente e non sempre si
vuole che i propri dati varchino le porte della propria organizzazione,
altrimenti per il resto sono d'accordo con te, meglio un backup
ridondato oltreoceano, magari dopo una bella crittografazione. Ma,
appunto, dipende da tante cose, anche da quanti sono i dati e da quali
sono i criteri e la frequenza del backup.
Diciamo che le casseforti hanno un loro perchè.
Ale

 Preferisco unita' esterne sulle quali VEDI i maledetti file.
I nastri devono essere l'ultimo anello nella catena di gestione dei backup. 
L'uso di hard disk esterni, CD/DVD/BD o NAS remoti dev'essere un anello 
intermedio, in quanto non ti danno sicurezza contro manipolazioni 
accidentali o contro l'usura del tempo
Enrico

 a blocchi del database o corruzione degli archivi
Se si ragiona a livello di affidabilita` sulla gestione del dato ti potrei 
anche dare ragione, se si ragiona a livello di operativita` allora possiamo 
tranquillamente dire che MySQL sia da evitare :)
Enrico

 basandoti sul database, se vuoi fare un bel lavoro, falla multidatabase.
Scelta interessante, ma prona a complicazioni probabilmente non volute. Se 
si dovesse seguire questa strada, allora e` consigliabile usare un ORM
Enrico

 indeciso se utilizzare un database firebird o mysql.
Sei fortunato, vedendo le tue preferenze la scelta si basa ovviamente su 
Firebird. Discorso differente invece se tra le tue preferenze ci fosse stato 
PostgreSQL, ma per fortuna non e` cosi` :)
Enrico


Che c'hai contro Postgresql ? 

 Che c'hai contro Postgresql ?
Contro PostgreSQL nulla, anzi, e` la mia prima scelta quando devo svilppare 
qualcosa su database, seguita da Firebird e SQLite :)
Enrico

 qualcosa su database, seguita da Firebird e SQLite :)
Uso Firebird, ma credo di aver capito che PostgreSQL sia più completo.
La cosa che mi sorprende, però, è che Firebird gestisce database anche  
molto gradi con la massima facilità di installazione e di gestione, e con  
un solo file che puoi tranquillamente chiamare MIOFILE.FDB (neanche  
Access...), mentre PostgreSQL ha bisogno di centinaia di file dal nome  
misterioso e molti parametri di settaggio. Naturalmente, questi non sono  
un ostacoli in per sé, però io continuo a non capire dove incomincia di  
preciso il valore aggiunto di PostgreSQL rispetto a Firebird.
-- 
Michele

 preciso il valore aggiunto di PostgreSQL rispetto a Firebird.
Un po' di esempi:
 - Ricerca fulltext integrata;
 - Performance piu` alte;
 - Dimensione dei record piu` alte;
 - Supporto a piu` linguaggi per le stored procedure;
 - Supporto piu` esteso agli standard ANSI SQL;
 - Replica integrata.
Sostanzialmente l'uso di Firebird o di PostgreSQL dipende molto dalle 
caratteristiche del progetto che si intende sviluppare (De Lapalisse e` un 
mio caro amico :) ). Firebird e` rivolto a quei progetti in cui la 
portabilita` e/o la scalabilita` sono prioritarie rispetto ad altri aspetti, 
PostgreSQL invece e` rivolto a tutti coloro che hanno bisogno di 
flessibilita` e funzionalita` specifiche nella gestione dei propri progetti. 
Per quanto riguarda la strutturazione dei datafile, e` decisamente una 
conseguenza dell'impostazione del progetto. Prendere i datafile di 
PostgreSQL e riutilizzarli su di un altro server non serve a nulla, in 
quanto le strutture interne sono univoche per istanza. Di contro, non e` 
vero che un database Firebird sia composto univocamente da un datafile, in 
quanto e` possibile suddviderlo su piu` datafile, senza contare che puo` 
esserne creata una copia shadow in qualsiasi momento
Enrico

 Michele wrote:

Grazie. Come sempre disponibile e generoso nelle risposte.
Adesso manca solo un case study... :)
-- 
Michele

 Adesso manca solo un case study... :)
Beh, un case study te lo posso fornire io stesso: 
https://bitbucket.org/ebianchi/yds/overview
Il progetto e` sviluppato in Java e si propone di indicizzare tutti i 
documenti presenti in un determinato percorso. L'uso di PostgreSQL e` dovuto 
essenzialmente a tre fattori:
 1) Implementa un sistema di ricerca fulltext interno;
 2) Mi permette di avere ottime performance;
 3) Per il futuro (remoto :) ) vorrei implementare una interfaccia web per
    l'estrazione dei dati.
Enrico

     l'estrazione dei dati.
non capisco in che senso questo è un punto a favore: sempre per la  
programmabilità nativa in Java?
Ancora grazie.
"
-- 
Michele

 programmabilità nativa in Java?
Piu` che per la programmabilita`, pensavo alla gestione dei dati (ovvero, 
perche` ho usato PostgreSQL e non perche` ho usato Java). L'uso di Java e` 
un collaterale del fatto che mi interessava avere un'applicazione 
multipiattaforma e che avesse delle librerie native (ovvero niente wrapper a 
comandi esterni) per la manipolazione dei dati
Enrico

 (partizionamento logico dei dati), Firebird ne usciva con le ossa rotte
...con le ossa rotte. Interessante.
Mi sembra di capire, però, che i problemi non sono dovuti né alla mole di  
dati, né alla mole di accessi concorrenti.
Purtroppo, però, l'espressione "partizionamento logico dei dati" a me fa  
venire in mente solo la distribuzione in tabelle+join, e non credo che  
vuoi intendere questo, perciò ti chiederei qualche spiegazione ulteriore.
-- 
Michele

 vuoi intendere questo, perciò ti chiederei qualche spiegazione ulteriore.
E invece hai capito bene :)
Il test che ho eseguito era il seguente: n tabelle identiche contenenti solo 
un range di dati (indicizzati) e una vista che le aggregava. Le query erano 
pensate per prendere i dati da almeno due delle tabelle fisiche (ovviamente 
le clausole di WHERE utilizzavano gli indici). In queste condizioni, 
PostgreSQL e` risultato molto piu` veloce di Firebird, in alcuni casi, di 
almeno 10 ordini di grandezza. Prima pero` di tirare le conclusioni, 
tieniamo in considerazione tre fattori:
 1) Il mio test e` riferito ad una casistica ben specifica, che potrebbe
    pero` essere rappresentativa solo in determinate occasioni.
 2) La scelta di un RDBMS non puo` e non deve essere condizionata solo da un
    determinato fattore. Nel caso specifico, utilizzare PostgreSQL rispetto
    a Firebird potrebbe precludere lo sviluppo dell'applicazione in
    determinati ambiti (e.g. embedded).
 3) Ultimo, ma non per importanza, PostgreSQL dispone di una comunita` molto
    piu` grande rispetto a Firebird, e questo gli permette di avere a
    disposizione molte piu` risorse, sia a livello di installato (e quindi
    bug tester), sia a livello di sviluppatori attivi. Firebird, dal suo
    canto, ha molte meno risorse, e di conseguenza deve quindi focalizzarsi
    prima su aspetti piu` essenziali (e.g. stabilita` e sicurezza) e poi sul
    resto
Enrico

     resto
Lo penso anch'io, ed è per questo che mi ha stupito aver letto (dove? non  
lo trovo più...) che Firebird è il quarto database, dopo Access, Oracle e  
MyQSL ad essere ricercato su Google. Certo, curiosi non vuol dire  
sviluppatori...
-- 
Michele


Cosa usi per interfacciarti a Postgres? Cioè quale componente o 
libreria?
-- 
Scrivo su Usenet da quando il Mar Morto era solo indisposto.

 libreria?
Ehr, nulla? :)
Seriamente, nonostante segua con interesse Delphi e Object Pascal, ancora 
non ho trovato un motivo valido per adoperarli in produzione. Comunque sia, 
visto che userei FreePascal, e che le Zeos lib sono decentemente usabili 
solo con Lazarus, userei i binding messi a disposizione con il progetto 
FLOSS
Enrico

 sviluppatori...
Beh, e` pur sempre una consolazione, direi, alla fine Firebird e` ottimo :)
Enrico

 :)
Non ho la tua esperienza, ma concordo.
Grazie.
-- 
Michele

 I nastri devono essere l'ultimo anello nella catena di gestione dei backup.
I nastri vengono ancora usati massicciamente per trasportare grosse
quantitatà di dati scientifici da un centro ad un altro fisicamente 
distanti (tipo da italia a germania).
Un esempio? I dati di un centro di calcolo scientifico: dato che vengono 
generati terabyte di informazioni al secondo, per trasportare petabyte 
di risultati da un centro ad un altro, la via più veloce consite nel 
salvare su centinaia di nastri i dati e poi trasportare fisicamente in 
nastri a destinazione.
Se si facesse il trasferimento via fibra il costo sarebbe di gran lunga 
maggiore e richiederebbe un tempo esponenziale per trasferire tutto.
-- 
morde
D5,D6,D7
QT 4.7.0 - MingW- QT Creator 2.1

 maggiore e richiederebbe un tempo esponenziale per trasferire tutto.
e perche' non usare degli hdd ?
Adesso non so di che trasferimenti parli, ma io ho avuto un paio di volte  
l'occasione di trasferire qualche decina di tera di materiale, ed abbiamo  
usato hard disk
-- 
=============================================================
Alberto Rubinelli - Fondazione "Museo del computer"
Via Costantino Perazzi 22 - 28100 NOVARA - ITALY
Tel 0321 1856032   Fax 0321 391769   BBS 0321 392320
Mail: 
alb...@oldcomputers.de
Sito internet : 
http://www.museodelcomputer.org
=============================================================

 e perche' non usare degli hdd ?
Credo che dipenda dal costo, dalla capienza e dalla vita del dato: 
spostare decine di tera ha un costo che forse può essere ammortizzato 
acquistando HDD che poi vengono riutilizzati, ma se questi dati fossero 
migliaia di volte più grandi e devi storicizzarli, non so se gli hdd 
restano il media più economico.
I nastri sono anche archivio storico: tutti i dati in esso contenuti 
vengono resi offline e deposti nei datacenter.
Un esempio? i calcoli matematici dei modelli metereologici. Se vuoi 
accedere ai calcoli dei supercomputer fatti in occasione di una tempesta 
di tornadi accaduta cinque anni fa, quei dati saranno ormai offline e 
dovrai recuperarli da un datacenter tramite robot automatizzati che 
prelevano da centinaia di armadi i nastri archiviati a suo tempo.
Partendo da wikipedia guarda cosa si può conoscere sui nastri (e tutti 
li credevamo in via di estinzione)
http://en.wikipedia.org/wiki/Magnetic_tape#Data_storage
ottima anche la presentazione del ceo di imation:
http://www.imation.com/euc/pdfs/EUC_07_Qualls.pdf


 prelevano da centinaia di armadi i nastri archiviati a suo tempo.
In non pochi casi, al momento di rileggerli, i dati sono illeggibili :(
Anche sui nastri va fatta manutenzione, purtroppo.
Forse la cosa migliore, per spostare grandi moli di dati, e' non lasciare  
che si accumulino ... in questo modo anche con linee non galattiche, si  
puo' mantenere la sincronizzazione.
certo ... non oso pensare al disaster recovery :)


 C'è qualche ragione particolare per mettere l'indice su un campo DATE?
Beh, considerando che la query e` su di un dataset parecchio corposo, direi 
di si :)
Enrico

 e perche' non usare degli hdd ?
Perche` mediamente un hdd e` piu` fragile e vulnerabile di un nastro. 
Esempi:
 - Prendi un nastro ed un hdd, dopodiche` lasciali cadere da un metro di
   altezza. Nella malaugurata ipotesi che la cassetta protettiva del nastro
   vada in mille pezzi, puoi prendere un'altra cassetta e montare il nastro
   in quella. Nel frattempo, l'hdd e` da buttare :)
 - Lascia un hdd montato sul pc ed il nastro nel suo lettore, dopodiche` fai
   saltare la corrente. L'hdd richiede come minimo uno scandisk per il check
   dei dati, con la malaugurata possibilita` di aver perso tutto, il nastro
   no.
Enrico