Newsgroup: it.comp.appl.access
Titolo: Sistema multi-aziendale con anagrafiche in comune

Supponiamo di avere il classico gestionale con gestione vendite
Il signor Rossi, titolare della ditta Pippo srl, dispone del gestionale 
col quale fare gestire le vendite
Il sig. Rossi decide di avviare una seconda ditta, la Paperino snc che 
ha come attivita' principale la stessa della ditta Pippo srl
Il data center de sior Rossi e' unico e dispone dei sistemi per la 
gestione sia della prima che della seconda ditta
Sarebbe utile per lui, che i due gestionali usati nella prima ditta e 
nella seconda condividessero le stesse anagrafiche clienti/fornitori, ma 
solo le anagrafiche
 
1-Possibilita'
Dal punto di vista dell'ambaradan che memorizzera' i dati, pensavo di 
sdoppiare completamente i due sistemi, quindi gestionale1 collegato a 
db1, e gestionale2 collegato a db2
Poi consentire la configurazione del gestionale in modo che sia 
consentito il collegamento, limitatamente alle tabelle/query contenenti 
le anagrafiche, ad un qualsiasi db
Quindi il gestionale2, per quanto riguarda le anagrafiche, agira' sulle 
tabelle contenute nel db1
In sostanza ogni programma usera' il proprio db, ma potra' collegarsi ad 
un altro db per la gestione anagrafiche
Se fossero due installazioni, 2 programmi + 2 db
Se fossero cinque installazioni, 5 programmi + 5 db
 
2-Possibilita'
Ogni gestionale avra' (di serie) due db per memorizzare i dati, 
db_anagrafiche+db_tuttoilresto
Se fossero due installazioni, 2 programmi + 3 db
Se fossero cinque installazioni, 5 programmi + 6 db
 
La domanda e': se doveste fornire un sistema che debba consentire di 
mettere in comune tra piu' gestionali un set ristretto di informazioni, 
voi come fareste (possibilita' 1, possibilita' 2, altro) ?
Ciao e grazie

Personalmente io per un gestionale multiditta uguale in tutto e per tutto ho aggiunto pian pianino IdDitta a tutte le tabelle, aggiornato le procedure coinvolgendo sempre IdDitta. Log iniziale x scegliere la ditta. Semplice e indolore. Ho previsto una ditta master, fittizia, che mi permetta di aggregare i dati, c'è ne fosse la necessità

After serious thinking RobertoA wrote :

Un db per le tabelle (BackEnd) al quale si relaziona un
altro db (FrontEnd) coi programmi, form, report, etc,
e così per ciascuna ditta (e sono 4 db).
Un quinto db (altro BackEnd) con le sole anagrafiche CLI/FOR
comuni al quale si relazionano ambedue le ditte.
 
Bruno


Che e' in sostanza la mia possibilita' 2
Quello che volevo capire era se ci fossero dei contro a tenere le 
anagrafiche dentro lo stesso db degli altri_dati
Oppure, visto dall'altro punto di vista, ci sono vantaggi a tenere db 
separati per anagrafiche e altri_dati ?
Mi sembra la stessa cosa, ma forse, non avendo praticamente affrontato 
praticamente il problema, mi sfugge qualcosa
 
 

 
 
Quindi in un db fisicamente unico tieni tutto e separi con l'indicatore 
presente su ogni record?
Si, anche cosi' e' possibile
Anzi forse e' consigliabile perche' eventuali conteggi aggregando tutte 
le ditte sarebbero piu' semplici rispetto all'unione di piu' db 
fisicamente distinti
Per contro sarebbe un db delle dimensioni doppie, triple, quadruple

Non proprio. Molte informazioni sono le stesse (tabelle di decodifica, anagrafiche....) io ho trovato piuttosto semplice il passaggio in questa maniera


Tieni conto anche che, nell'ipotesi dell'utilizzo in rete e in multiutenza, è fortemente sconsigliato tirar query su db differenti, magari poi eterogenee, tipo SQL server e mdb. Rischi di veder performance sotto i piedi anche per le cose più semplici.....In passato avevo seguito la strada di vari db, con un relink al volo a seconda delle ditte, addirittura degli anni, ma ho reputato la soluzione non ottimale. Era tutto un 'trigger' per mantenere sincronizzati i vari db, un macello insomma. Ora, che per spazio e performance non ci sono gli stessi vincoli di 10 anni fa, non mi verrebbe neanche in mente. Sempre un DB unico. Al massimo, si può pensare ad una storicizzazione dei dati, se ci fosse la proprio necessità. Ma si parla di milioni di record e di taaaanti anni d'utilizzo

RobertoA formulated the question :

Vorrai scusarmi ma qui proprio non ti capisco.
 
Ribadisco comunque che io non avrei dubbi nemmeno per un secondo:
ciascuna ditta coi propri BackEnd e FrontEnd e un secondo BackEnd
per le anagrafiche in comune.
La soluzione adottata da Roberto Fabbri, originale e ancorché
regolarmente funzionante, mi sembra, absit iniuria verbis... orrenda!
 
Bruno


Mi interessa molto la tua esperienza/opinione
Perche' la consideri orrenda?

RobertoA laid this down on his screen :

Mi dispiace averlo detto... non vorrei ti sentissi offeso.
 
"ho aggiunto pian pianino IdDitta a tutte le tabelle": non mi piace
per niente per una questione estetico-procedurale.
Poi funziona benissimo e meglio di come farei io,
non lo metto in dubbio.
 
Controdomanda:
dicendo "piano piano" immagino che il multiditta sia stato
impiantato sopra un già esistente progetto mono ditta.
Dovessi rifare from scratch un nuovo progetto multiditta
useresti lo stesso sistema?
 
Bruno

Nel mio caso si, Bruno. Si tratta di una ditta con diverse sedi. Ma stessa ditta. Quindi, movimenti divisi x singola sede, ma anagrafica clinti/fornitori, catalogo, fatturazione ecc comune. Impensabile sparpagliare o sincronizzare i dati. Aggiungendo un ID, si é avuto il tempo e il modo, senza fermare il lavoro, di ottenere l'update a caldo, testando una parte alla volta del programma. Rimarco il fatto che, x avere aggregati, é oltremodo sconsigliato avere basi dati sparpagliare. Una query sul pc tra tanti mdb non ha nessun problema, ma non appena sei collegato da un'altra macchina tutto va a pallino, generando rallentamenti e traffico elevato. Ricercando un po' prima di utilizzare questa strategia, avevo dB divisi x ditta. Le procedure x elaborare aggregati o tenere traccia di chi/dove faceva cosa occupavano metà programma. In questa maniera invece hai in effetti un solo programma da mantenere, con tutto ciò che comporta, procedure univoche e dati immediatamente disponibili, separati o aggregati x diverse sedi. Mi ha permesso anche di non modificare più nulla quando le sedi da due sono salite a tre. Oppure a n. È bastato aggiungere un'anagrafica in più dall'interfaccia utente, senza nessun intervento alla programmazione. Quindi si, ritengo, nel mio caso ovviamente, di aver utilizzato la strategia più semplice e funzionale possibile! Lo rifarei di certo, anzi ho appena consegnato un qualcosa di simile utilizzato x la contabilità di 4 aziende diverse, che fanno capo ad un unica persona, che può in questa maniera, gestirle in maniera separata avendo però sempre sott'occhio l'andamento complessivo delle sue attività. Un saluto


Forse ti riferivi a Roberto Fabbri
Non ho ancora ben capito la questione estetico-funzionale
E dovendo a breve imboccare una delle strade possibili ti sarei grato se 
esponessi quali problematiche pensi potrebbe incontrare una soluzione 
del genere
Sto parlando dell'archivio fisicamente unico, contenenti tabelle i cui 
record sono 'marcati' come informazioni di una certa ditta
La possibilita' di una semplice aggregazione dei dati mi sembra un pro 
di una discreta importanza
Cos'e' che non ti piace esattamente?
 
 
 

 Cos'e' che non ti piace esattamente?
Come dettagliato sopra, non mi piace proprio niente.
 
Bruno