Newsgroup: it.comp.software.database
Titolo: [lunghetto]DB replication - il modo piu' semplice?

Salve a tutti,sono fresco fresco di tutorial di mysql,e la mia conoscenza di
db e' estremamente superficiale,chiedo quindi venia per eventuali
svarioni....
Devo realizzare un programma gestionale per un amico,non per lavoro
ovviamente,ma anche per imparare.
Il problema è il seguente:il programma deve poter essere
multipiattaforma,quindi scritto in java,perchè usato sia da pc win,pc linux
e mac.
Ogni "client" deve avere una propria copia del db in locale,e quando
possibile devono aggiornare un server "centrale",e scaricare da esso
eventuali aggiornamenti fatti da altri client.
Ho trovato informazioni su mysql cluster,solo che mi sembra un poco
limitato,ovvero da quanto ho capito non funziona bene su internet ma solo su
rete locale (i client si connettono al server anche con un mitico
56k!!!),non supporta piattaforme diverse (questo mi sembra strano) e non
supporta le foreign keys (e questo ancora piu' strano).
Forse potrebbe aiutarmi ms sql server,ma ovviamente non credo riesca a
girare su mac.
Qualcuno potrebbe aiutarmi e mostrarmi la via?

 eventuali aggiornamenti fatti da altri client.
Questo è un vincolo molto pesante: ti comporta la necessità o di
appoggiarti a costosi schemi di DB distribuiti o a sviluppare
complicate procedure di sincronizzazione. Sei proprio sicuro che i
client abbiano bisogno di questo livello di autonomia?

 
Dai una occhiata a PostgreSQL e Slony-I (quest'ultimo però serve per le
replicazioni, non per quello che vuoi fare tu).
Un'altra soluzione è implementare qualcosa ad hoc, in modo semplicistico.
Se gli utenti non creano o cancellano nessuna tabella puoi dare una
occhiata al mio pglog, lo trovi su 
berlios.de
.
Un articolo è presente anche qui:
http://www.psql.it/?q=node/31
Ogni modifica viene memorizzata in una apposita tabella, con la
possibilità di rieseguire l'istruzione SQL per generere la data modifica.
Per tenersi sincronizzato con il server il cliente può restare in attesa
di ricevere una notifica (via TCP o UDP), scaricarsi i log ed eseguirli
sul suo database.
Oppure collegarsi di volta in volta per scaricare gli aggiornamenti.
Non è banale ma non dovrebbe essere troppo complicato.
Saluti  Manlio Perillo

 client abbiano bisogno di questo livello di autonomia?
Il gestionale e' per una scuola di vela,con un ufficio in citta' e la base a
100 km.L'ufficio in citta' registra le prenotazioni e tiene i conti,nei pc
"al mare" vengono registrati gli allievi,stampati i diplomi,archiviate le
schede,gestito il magazzino e la contabilita',etc etc,e non c'e'
possibilita' di comunicazione diretta (tipo adsl o web application).


[CUT]
Sembra interessante,oggi lo studiero'....

 possibilita' di comunicazione diretta (tipo adsl o web application).
Capisco che sia difficile, ma non impossibile, se è vicino ad un porto
turistico c'e' sicuramente copertura GPRS e potenzialmente anche wi-fi.
Tieni presente che anche se spendi un po' di connettività risparmi sia
in termini di sviluppo che di data protection: è evidente che il primo
non è una variabile significativa perchè siamo nella classica
situazione do-it-yourself, ma forse il tuo amico non ha pensato al
secondo problema: optare per la soluzione replicata comporta l'obbligo
di pensare a ridondare anche l'HW "al mare", backuppare tutto, mettere
gruppi di continuita, ecc. ecc. (e non credo che per amicizia tu gli
regali anche un disco RAID e uno streamer a nastro, oltre che il tuo
tempo ;))
bye!

 backuppare tutto, mettere gruppi di continuita, ecc. ecc.
Usare due db replicati non e' proprio ridondare e backuppare continuamente
le informazioni?In caso di guasto del "pc-mare" i dati si recuperano da
"casa",in caso di guasto a casa i dati si recuperano dai backup "di
routine"...in caso di guasto hardware...beh,il pc client e' quello del
capo,in caso di guasto se lo ricompra subito (gia' succsso 2 volte in un
mese.....)e il sistema puo' anche stare off-line per qualche giorno,non
succede niente.....

 eventuali aggiornamenti fatti da altri client.
Esiste un'altra soluzione, che è sempre bene tener presente: i servizi
di directory (è comunque un database, anche se di tipo particolare).
*SE* i dati in questione non rivestono un'importanza critica, o
semplicemente si è disposti a tollerare qualche occasionale anomalia,
in cambio si avranno consistenti benefici in termini di facilità di
utilizzo, prestazioni, scalabilità e replica.
Ti avverto subito che gran parte delle performances deriva proprio
dall'omissione di features che in un db classico garantiscono la
consistenza dei dati in ogni situazione, ma sarebbe comunque errato
scartarlo a priori (non tutti gestiscono una banca).
Il discorso è impossibile da esaurire in un singolo post,
specialmente considerando che molto dipende dall'analisi delle tue
esigenze.
Ti rimando pertanto, se non l'hai già fatto, a soluzioni tipo
OpenLDAP e simili, alla documentazione che lo confronta con un db
transazionale, per poi continuare con il supporto ai linguaggi etc etc.

 
Questo è un discorso che mi interessa molto.
Non tanto per la questione della replicazione, ma proprio come modello
per organizzare i dati.
Ad esempio mi sembra di aver letto che spesso LDAP viene abusato.
Saluti  Manlio Perillo

 etc.
Mi pare un poco complesso da imparare.....io avevo pensato ad una soluzione
un po' contorta ma forse piu' facile da scrivere,non so....
Situazione: pc in ufficio che lavora su un db su un server
   pc remoto che ha una copia esatta del db in locale.
Quando sul server viene aggiunto un record,ne vengono registrati i dati in
un log.Quando il remoto si collega al server,scarica il log e aggiunge i
records.
Se vengono aggiunti record dal pc remoto,questi vengono memorizzati anche in
un secondo db "temporaneo" sempre sul pc remoto,e una volta scaricato il log
dal server il pc remoto esegue queste operazioni:
1)elimina tutti i records inseriti sul pc remoto dall'ultimo aggiornamento e
li "sposta" in un secondo db temporaneo
2)aggiunge i records come scritti nel log
3)aggiunge i records eliminati al punto 1 leggendoli dal db temporaneo e lo
svuota
Ovviamente invia anche lui al server il proprio log con i records
aggiunti,che vengono inseriti dal server.
Eventuali query di aggiornamento vengono eseguite dopo che i dati siano
stati aggiunti.
Che ne pensi?Piu' semplice utilizzare ldap?

 Ad esempio mi sembra di aver letto che spesso LDAP viene abusato.
Tanto per far venire l'acquolina in bocca a te e all'OP, cito
brevemente che tipicamente i db tipo ldap sono:
- Multimaster: ciascun server possiede una copia dei dati e su quella
ha autorità completa; nessuno stallo per mancanza di sincronizzazione
con server remoti; si aggiorna in locale, poi è compito del server di
sincronizzarsi
- Replica e propagazione automatica: i db si sincronizzano ad
intervalli prefissati (o manualmente), scegliendo autonomamente il
path più breve; se un link va giù, automaticamente ne verrà usato uno
disponibile
- Funzionano anche su connessioni lente, con possibilità di caching
nel client per un accesso ultraveloce, funzionante anche dopo la
perdita di connessione al server
- I client non si bloccano a vicenda (nessun lock sui dati utente)
- Complessiva semplicità lato programmatore (specie se confrontato
con un db tradizionale...)
Per venire alla tua domanda, tra i punti negativi: nessun modello di
dati, nessuna integrità, nessun lock, nessuna stored procedure, zero
totale, zilk, tutto fatto tramite il tuo codice e tramite il
terribile "risolutore", un bieco sistema che sceglie quale
modifica vince basandosi... sull'ora di update :-(
In un certo senso, possiamo dire che un tale sistema potrebbe fornire
l'infrastruttura di un db a livello fisico, lasciando al
programmatore il compito di fare tutto il resto.

 Che ne pensi?Piu' semplice utilizzare ldap?
Dipende da te, da quanto sai già e da quanto vuoi studiare.
Più che altro, anche e soprattutto considerato che il tuo intento
è didattico, mi orienterei in ogni caso verso una soluzione che
sarà spendibile nel lavoro.

 
LDAP mi interessa ma non voglio mettermi ad imparare una nuova tecnologia.
Per ora i database relazionali mi vanno bene (e non li sfrutto nemmeno
al 100%).
Certo, a volte devo fare degli hack (vedi il mio post sul consiglio per
un modello per un calendario), ed è noioso interfacciarsi;
e poi io lo faccio alla "vecchia maniera" con interfacce tipo:
class ICalendarStore(Interface):
  def getEventById(id):
     """Return an object implementing the IEvent interface.
     """
  ...
class IEvent(Interface):
  def reschedule(dtstart=None, dtend=None):
      """Reschedule an event.
      """
Che poi mi implemento per ogni database che uso (di solito SQLite e/o
PostgreSQL), usando query scritte "a mano".
Una alternativa è usare un database "ad oggetti", come Axiom
http://divmod.org/trac/wiki/DivmodAxiom
ma non mi fido molto.
I database relazionali saranno anche spesso sottosfruttati, ma
permettono un design stratificato con le varie parti che interagiscono
attraverso interfacce ben definite (ed a me questo piace).
Il layer database ha una vita propria: ottimizzazione db, query, view,
stored procedured, etc.
Certo, a volte mi chiedo se valga la pena questo approccio per progetti
semplici. ;-)
Saluti  Manlio Perillo

 semplici. ;-)
Sisi, sempre, anche per una guida del telefono :-))))))

 
Io sono del parere che una volta padroneggiata una *buona* tecnologia si
debba cercare di spenderla il più possibile (ovviamente entro certi
limiti e senza abusarne).
Infatti se uno ne diventa pratico riesce comunque a compensare i
maggiori tempi di sviluppo.
Saluti  Manlio Perillo

 le informazioni?
Ti contraddici da solo. Se non c'e' modo di effettuare un collegamento
di rete affidabile, com'e' possibile che i DB siano replicati
"continuamente"? Nel migliore dei casi potresti usare un modem ed un
telefono normale per lanciare la replica, e a quel punto c'e' da vedere
ogni quanto lo fai. Se l'uso è poco e si fa poco "lavoro" due o tre
volte al giorno, potresti anche connetterti quando ti serve
l'applicazione. Se invece fai tanto "lavoro", o replichi di continuo (e
allora si torna al fatto che devi stare sempre collegato), o prendi
delle precauzioni per impedire di perderlo. Ma da quello che dici mi
sembra di capire che comunque è tutto poco più che un giochetto,
quindi fai un po' come ti pare ;)
bye!

 Non lo sapevo.
Altroché, e quanto rompevano!!! "Relational model is dead", "We need
a more flexible model, that fit better to your OO language", "RM is
thing of the past" blablabla; eccoci invece ancora qua, l'ondata sta
passando e il modello relazionale galleggia benissimo.
Ah, c'è da dire che la storia si sta ripetendo con gli XML "database",
ma prevedo che dureranno anche meno ;-)

 
Però credo sia indubbio che ci serva un ponte migliore tra linguaggi OO
ed un database relazionale.
Io, come detto, non mi fido molto dei database ad oggetti "self made",
come, nel caso di Python, ZODB e Axiom.
Comunque sono contento che il modello relazionale si sia rilevato
solido, ora devo solo trovarvi un buon libro da studiare. ;-)
Saluti  Manlio Perillo

 solido, ora devo solo trovarvi un buon libro da studiare. ;-)
Vai per gradi, senza esagerare.
Ciao

 Vai per gradi, senza esagerare.
Il problema per ora è decidere quale libro usare, dato che non voglio
specializzarmi in database, quindi ne vorrei comprare solo uno (giusto
perchè mi piace avere piena padronanza degli strumenti che uso).
Saluti  Manlio Perillo

 perchè mi piace avere piena padronanza degli strumenti che uso).
Solo un libro, hum difficile ma non impossibile.
Purtroppo in giro c'è veramente tanta robaccia...

The man with two watches ha scritto:

C'è il testo Fundamentals of database systems di Elmastri, ma temo sia
uno di quei testi enciclopedici che spiegano tutto e niente.
Nella FAQ del gruppo è anche suggerito Database Design for Mere Mortals.
In alterativa c'è il testo di Date.
Manca qualcosa?
Saluti  Manlio Perillo

 Manca qualcosa?
Solamente qualche quintalata :-)


Non è un problema che ci siano troppi argomenti, purchè:
- quello fondamentali non ne risentano
- il libro sia ben scritto e piacevole da leggere
Tra l'altro il mattone di Elmastri è stato diviso in due nella edizione
italiana.
Saluti  Manlio Perillo

 - il libro sia ben scritto e piacevole da leggere
Dunque, mi sbilancio un po': dati i tuoi obiettivi, ti sconsiglierei
i titoli accademici; piuttosto ti orienterei verso i libri di design.


Database Design for Mere Mortals come è?
Non vorrei fosse del tipo:
"tutto quello che avresti voluto sapere sul come lessare le patate" ;-)
Saluti  Manlio Perillo

 "tutto quello che avresti voluto sapere sul come lessare le patate" ;-)
Non lo conosco, sorry.

 
Quali testi conosci/suggerisci?
Magari si potrebbero ampliare le FAQ.
Saluti  Manlio Perillo


Mi sono ripromesso di non suggerire libri; siccome non conosco tutti
i testi in vendita, non posso sapere se di un dato libro che mi
piace ne esiste un altro migliore.
Oltre al fatto che sarebbe come consigliare un vestito ad un estraneo,
se ti consiglio uno dei miei preferiti (85 sacchi), se poi non ti
piace e ti andava bene uno da 30...

 
Ma io mica compro un testo ad occhi chiusi!
Prima cerco di leggerne alcuni estratti.
La lista di libri nelle FAQ è troppo scarna ed andrebbe ampliata.
Saluti  Manlio Perillo