Newsgroup: it.comp.appl.access
Titolo: Archivi distribuiti

Ma chi l' ha detto che i dati debbano essere salvati solo su
un sistema centrale ? Ma va la.
Infatti :
Cos' e' in fondo un utente se non un archivio di dati
(informazioni, conoscenze, regole ecc ecc)  il tutto
coordinato da un software ESTREMAMENTE paraculo
(ovvero : la sensibilita' tipica di noi umani) ?
Se allora  *tutti*  i dati dovessero DAVVERO essere solo
centralizzati, gli utenti potrebbero pure essere soppressi.
Assurdo.
Ma allora, se gli utenti stessi non sono che archivi
distribuiti, perche' rinuciare a questo concetto ?
Il futuro, il presente ed il passato delle base dati e'
QUINDI un insieme di archivi distribuiti e POCO MALE
se i dati sono ripetuti negli archivi locali e in quello
centrale !  Anzi, meglio fare piu' copie della chiave di
casa ... Se te ne perdi una entri lo stesso.
La cosa davvero importante e' che tutti questi sistemi
possano facilmente interagire per (all' occorrenza)
"allineare" le loro conoscenze !
utente(che non e' altro che un archivio col suo software)
parla con un software che attinge dati dall' archivio
centrale, li elabora localmente, li mostra all' utente e
se il caso passa i risultati delle elaborazioni + i dati
eventualmente immessi dall' utente all' archivio centrale.
utente <-> DB locale <-> DB centrale
Ma anche
utente <---------------------> DB centrale
Ma anche
DB locale <-> DB centrale
In un continuo, incessante va e vieni, leggi e scrivi.
Rinunciare ad archivi distribuiti significa auto limitare
la flessibilita' e la potenza elaborativa del sistema tutto
(che in assenza puo' far elaborare solo una macchina)
in maniera ESIZIALE, devastante. Stupida, in fin dei
conti.
Soprattutto se si dispone GIA' di un grande main frame
e una costellazione di potenti pc, centinaia e centinaia,
e server esterni, che circondano, avviluppano e proteggono
il CUORE : il main frame. In una comuncazione di tipo
a stella, con varianti.
Vi sono anche altre ragioni a sostegno di questa
tesi. Una e' la semplicita' :  creare archivi e software
distribuiti e' COME SE si creassero ex novo oggetti
autonomi indipendenti SENZA modificare una virgola
del sistema centrale : una specie di super programmazione
a oggetti.
Ci credo molto a questa cosa, e lottero' fino all' ultimo
per farla passare in azienda.
Scusate lo sfogo, ma se non le dico a voi queste cose,
a chi le dico ?
Un abbraccio a tutti.

 Un abbraccio a tutti.
E' interessante quello che dici ma ci sono molte controindicazioni.
Quello che vuoi fare tu � una programmazione parallela. La mia tesi di 
laurea fu proprio basata su questo, parallelizzare una elaborazione 
programmandola sul singolo Transputer in modo da scalare la potenza di 
calcolo generale.
Ma...
qui parlavamo di semplici cpu collegate insieme e che si scambiavano 
informazioni a basso livello.
per una base di dati complessa devi replicare tutte le motivazioni che hanno 
portato alla scelta di un server centrale, su tutte le macchine periferiche.
Il server... ooohhh
il macchinone, costoso, potente, con backup freddo e caldo
Sempre acceso e funzionante.
Tu puoi garantire che tutte le macchine periferiche possano avere queste 
caratteristiche.
E ancora, i collegamenti...
Se la struttura di collegamento non pi� tra client e server ma tra tutti i 
client non � pi� che potente e non ci sono intoppi, quello che vuoi fare non 
funziona pi�, rallentando se non bloccando le elaborazioni.
Ci sarebbero altre cose, ma c'ho un attimo di fretta e mi riprometto di 
intervenire.
Per concludere cmq la tua idea � buona, ma si scontra su alcuni limiti 
prettamente fisici di realizzazione.
Per� se c'hai un pacco di soldi per far installare tutto quello che serve... 
oh, facci sapere...
Antonio 

 Antonio
A me di primo impatto vengono in mente cose come macchine in clusters e 
NAS, tecnologie DFS, sistemi RAID, beowulf e cose simili.
Certo, alcune costano un botto, altre meno, ma come diceva il dottor 
Frankestin: "SI...PUO'...FAREEE!!!" ;)
Cmq parlando per esperienza diretta, gestire una cosa del genere ï¿œ 
tutt'altro che facile, bisogna vedere se ne vale veramente la pena.
Saluti
Claudio(BS)

 
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--


Allineare... repliche su repliche su repliche.
Sono state scritte enciclopedie...
Ridondondondondondanza e il meccanismo crolla in un attimo.
Ho cambiato 6 residenze e il c/c � sempre lo stesso... eppure le 
comunicazioni arrivano in tutte e sei le residenze...

Quanti responsabili it pensi di avere in una struttura del genere.
Nel mio caso che mi occupo dal riscaldamento alla sostituzione del toner 
esaurito allo sviluppo two-tier client/server, alla manutenzione hw e sw 
dei pc ... una soluzione del genere diventa un suicidio.
E siccome credo che la politica onnipresente � risparmiare a tutti i 
costi... bh�...
Server centralizer per le policy, ma strizzando l'occhio sui client che 
in qualche modo possono alleggerirlo di inutili elaborazioni.
Immagina cosa succede se una policy aziendale viene modificata a causa 
di decisioni della direzione... chaos totale... o sviluppo costosissimo...
Non � poi quello che succede ogni giorno con i browser e le tonnellate 
di addin... i dati inviati sono pochi kb poi il client elaborer� tutti i 
brillocchi
Ti cito 
http://en.wikipedia.org/wiki/Client%E2%80%93server_model
 c'� un 
documento di 90 pagine!
Ciao
-- 
Daniele
Rispondere scartando OneEDP, spam e 32

> Un abbraccio a tutti.
Quanto durerebbe un sistema straridondante con sincronizzazioni di dati 
asincroni alla "n" ?... io credo che durerebbe 5 minuti.... sarebbe bello, 
ma non credo funga... 

 wrote:
Rispondo a me stesso per rispondere a tutti.
1)
Nessuna "stra-ridondanza"
2)
Nessuna "velleita'" che i db locali conversino tra loro.
Per il punto 1) :
il db locale produce ed elabora i suoi dati, ma SOLO il sottinsieme
di questi che si ritiene debbano essere visibili a tutti debbono
essere scaricati sul centrale.
E nulla vieta di considerare, dopo avvenuto lo scarico, l'
eliminazione
di quegli stessi dati  dal DB locale.
(Ma questo dipende da considerazioni non generalizzabili, cioe' da
vedere volta per volta)
il db locale pero' , ogni volta che elabora in funzione dei suoi
dati e di quelli centralizzati (e questo non accade sempre :
molte elaborazioni possono essere fatte solo in funzione dei
dati locali, quelli non condivisi) allora ALLINEA -quei- dati
col centrale (perche' nel frattempo potrebbero essere stati
modificati).
2)
Il db locali non conversano tra loro, ma solo col centrale.
Il collegamento deve essere rigorosamente a stella.
Non e' soverchiamente difficile mettere in piedi una
struttura del genere, basta strutturare con precisione
quali sono, per ogni DB locale :
- i dati da condividere e quelli da non condividere
- le elaborazioni che usano dati solo locali
- le elaborazioni che usano dati solo centrali
- le elaborazioni che usano dati misti
E' molto impegnativo, me ne rendo conto.
Ma anche estremamente POTENTE e infinatamente
scalabile.

 oh, facci sapere...
Lavoro in una banca, abbiamo TUTTO.
Ma non sanno adoperarlo a pieno.

 ha scritto nel messaggio 
news:ebc2c268-4400-4560...@w19g2000yqb.googlegroups.com...

Si ma a sto punto fa un esempio, cos� capiamo cosa vuoi fare... cosa fa un 
db locale, cosa fa un altro db locale, cosa fa il centrale, e come la 
sincronia dei dati avviene nel tuo disegno...
io per es. ho un sistema distribuito in tutta italia e interconnesso (in 
VPN) proprio con una struttura simile... c'� il DBcentrale (nazionale) che 
sfrutta SQL server connesso ai client con i DSN, con determinati dati, poi 
c'� il DB Server (Access) locale sulle "n" filiali distribuite sul 
territorio italiano, con altrettanti altri dati, poi c'� il DB Client 
(Access) locale sugli "n" PC delle "n" filiali. Il sistema � complesso 
soprattutto nel trovare un compromesso tra velocit� di esecuzione, 
sincronismo e sicurezza, perch� basta un semplice dato in pi� rispetto al 
necessario, richiesto al server centrale che lo rimanda in filiale 
processandolo poi con un dato del DB Server locale a sconquassare un 
equilibrio di per s� molto delicato. Bisogna disegnare bene flussi, tabelle, 
e sapere soprattutto benissimo il come, il quanto e il quando...
Tu, cosa ti proponi di fare?


Comunque nulla di nuovo. Per esempio i sql server con le repliche. 
Sottoscrittori, pubblicatori, distributori ecc. ecc...


Si ma a sto punto fa un esempio, cos capiamo cosa vuoi fare...
Troppo lungo.
Pizza con Alessandro Cara e ne parliamo ?
Offro io.


Solo se venite da me a Napoli (non so' se mi spiego "Napoli" =
"PIZZA"!!!!)... e ovviamente, a casa mia, offro io... ;)


Napoli ? NAPOOOLIIII ??? Sei di Napoli ? Io i napoletani
li ADORO ! Io ci sto ! :D  SISSI' !
Bisogna convincere Alessandro. Alessa CI LEGGI ?
CHE DICI ? ANNAMO CO LA MACCHINA MIA ?
Ehm ...
Pero' aoh, famise a capi' ... c' ho la macchina nuova, al
parcheggio *tranquillo* ci pensi tu, si ? Garantisci ? ;-)

 parcheggio *tranquillo* ci pensi tu, si ? Garantisci ? ;-)
Io garantisco per me... ;)

 Io garantisco per me... ;)
... Tu a Roma un salto lo faresti ? ;-)