Applicativo gestionale multi azienda

lunedì 18 gennaio 2010 - 12.11

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

enricovirg Profilo | Newbie

36 messaggi | Data Invio: lun 18 gen 2010 - 12:11

Devo sviluppare un applicativo gestionale che dia la possibilità di gestire più aziende, ovvero
che si può usare lo stesso software per gestire in maniera indipendente varie società...
es.
Azienda Pippo SPA compra il software che gli servirà per gestire oltre che Pippo SPA anche altre aziende del gruppo (Paperino SRL e Pluto SNC).
A questo punto mi chiedevo quale fosse la strada migliore:
a) Unico database, e per discriminare la competenza dei dati usare un campo id_azienda nelle tabelle...
b) 1 database per ogni azienda

attendo commenti/consigli in merito...

AntCiar Profilo | Expert

936 messaggi | Data Invio: lun 18 gen 2010 - 12:17

Ciao. Io utilizzerei un DataBase per ogni azienda in modo da non avere una "insalata" di dati (anche se opportunamente contrassegnati).
Se poi è previsto lo scambio di dati tra più aziende allora ti conviene un unico database in modo da non dover sbattere la testa con eventuali contatori duplicati e altro.
Cristian Barca

Jeremy Profilo | Guru

1.527 messaggi | Data Invio: lun 18 gen 2010 - 12:22

Ciao Enrico.
>A questo punto mi chiedevo quale fosse la strada migliore:
Decisavamente 1 un database per ogni azienda.

.

Facci sapere...
Ciao

enricovirg Profilo | Newbie

36 messaggi | Data Invio: lun 18 gen 2010 - 13:42

anche io sarei propenso ad avere un database per ogni azienda,
ma ,magari mi sbaglio, a me pare più difficoltoso da gestire:
- script di creazione database ad ogni possibile nuova azienda,con ciò che ne comporta...
- eventuali modifiche su tabelle,viste,stored procedures andranno fatte su ogni database (voglio mantere il tutto il più uniforme possibile)

mmmmah...

tonyexpo Profilo | Senior Member

229 messaggi | Data Invio: lun 18 gen 2010 - 14:04

Ciao
in effetti se vuoi che esistano utenti in grado di gestire una anagrafica di aziende, queste diventano parte del tuo applicativo, un entità a tutti gli effetti, quindi ti consiglierei di trattarla come tale e creare una tabella di anagrafica aziende. Il tuo problema sarà che in ogni altra entità del tuo db (anagrafica clienti, fornitori, prodotti, fatture, etc) dovrai sempre creare una chiave doppia (id + idAzienda) visto che lo stesso cliente puo essere censito per 2 o più società. a meno che il gruppo non voglia gestire i dati in modo centralizzato relativamente alle anagrafiche clienti/fornitori.
per i documenti contabili invece (fatture, note credito, ddt, etc) dovrai sempre procedere con chiave doppia

buon lavoro ;)

Antonio Esposito
MCTS, MCP

http://blogs.dotnethell.it/espositos

AntCiar Profilo | Expert

936 messaggi | Data Invio: lun 18 gen 2010 - 14:10

Non è molto difficile da gestire.
Noi abbiamo sviluppato una applicazione che lavora contemporaneamente su tre database MySql. Ogni cliente ha i suoi tre database. abbiamo implementato una procedura di aggiornamento che provvede ad aggiornare lo schema del DB con l'invio di un aggiornamento.
da noi in sede abbiamo più terne di database per il debug e il test. Alla fine una volta implementato il controllo e l'aggiornamento del DB connesso, hai anche implementato l'aggiornamento di tutti gli altri facendo si che all'avvio del programma venga controllato lo schema del DB a cui si è connesso. In questo modo non sei tu con l0'aggiornamento a dover sincronizzare tutti gli N database del cliente ma è il cliente stesso che lo fa quando si connette ad uno specifico database. Potrebbe sembrare una procedura dispendiosa dal punto di vista di tempo e risorse ma posso dirti che sui nostri database, che non sono certo piccoli, il tutto dura qualche secondo.
Cristian Barca

Teech Profilo | Expert

573 messaggi | Data Invio: mar 19 gen 2010 - 17:20

Io vado controcorrente e dico 1 database con identificativo nelle tabelle. Perchè?
1) Non tutte le tabelle sono prettamente aziendali e quindi alcuni dati verranno duplicati, magari inputando ID diversi (tabella dei codici IVA ad esempio, ma ci sarebbero esempi decisamente più calzanti): le tabelle sovraziendali per intenderci.
2) La comunicazione fra le aziende è più semplice in termini di dati
3) Moltissimi gestionali multiaziendali che ho visto e implementato usano questa soluzione (quindi ritengo essere già collaudata e pensata)
4) Prestazionalmente è più il tempo di accesso al DB che non il filtro dei dati su tabelle di grosse dimensioni
Questi sono i principali motivi della mia scelta, tutti opinabili, ma io non ci penserei 2 volte a scegliere la soluzione a DB unico.
--------------
Maurizio Brini
--------------
Nessuna impresa è mai stata compiuta da un uomo ragionevole

enricovirg Profilo | Newbie

36 messaggi | Data Invio: mar 19 gen 2010 - 19:47

Si, alla fine ho deciso per un unico database con identificativo azienda sulle tabelle che lo richiedono.
Anche a me pare la soluzione "più gestibile", alla fine si tratta solo di gestire il parametro azienda sulle tabelle e query...

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !