DB unico pro e contro

[las]

Sto facendo un restayling strutturale di una piccola applicazione web-based di gestione aziendale (fatturazione, magazzine, clienti ecc.. ) ovviamente questa applicazione è usata da più clienti, e ciascuno di loro attualmente ha il suo bel DB mysql dedicato, e una cartella degli scipt dedicata.

Ora invece avrei deciso di unire tutti in un unico DB e conseguentemente fare un unica applicazione (una sola cartella script che vale per tutti) questo mi consentirebbe in caso di modifiche di risparmiare parecchio tempo, dato che adesso se ad esempio aggiungo una colonna in una tabella devo andare a farlo in tutti i DB, oppure se correggo uno script devo fare la correzione su tutte le cartelle.

Però allo stesso tempo potrebbe essere rischioso, perchè ad esempio nella tabella fatture avrei tutte le fatture del cliente A, tutte quelle del cliente B ecc.. è evidente che basta una piccola distrazione nella scrittura di una query e corro il rischio di far vedere ad A le fatture di B e viceversa.

Vuoi cosa consigliate? DB e applicazione unica per tutti o a ciascuno la sua? qualcuno ha avuto esperienze simili?

[fmortara]

imho ad ognuno la sua...

ok, unica cartella per i file con login separato, ma il db lo terrei separato.

[silverwings]

Assolutamente un db unico non so come hai potuto lavorare bene ora, mysql lavora molto bene anche con molti record se gestisci bene le tabelle,viste,storage ecc...

[telegio]

quoto silverwings..
devi ovviamente stare attento agli script, ma tutto in un DB e in una cartella è LA SOLUZIONE..

[maje]

anche io ti consiglirei un database unico: praticamente tutte le piattaforme mall/ecommerce su cui ho lavorato si basano su un unico database, e ci sono diversi motivi per farlo (strutturali, architetturali, ecc.). La sicurezza dell'applicativo non dipende poi così tanto dalla separazione dei database, e in rapporto a tante altre cose (costi, tempo, tecnologie attuali, ecc.) sicuramente l'utilizzo di un'unica base di dati è la soluzione ottimale.

Come dice silverwings le ultime versioni di MySQL lavorano molto bene, e puoi sfruttare appieno la potenzialità ad esempio di un bel database innodb!

[Santino83_02]

una domanda manco da porsi: 1 database. fatto bene.

[k.b]

Originariamente inviato da las
è evidente che basta una piccola distrazione nella scrittura di una query e corro il rischio di far vedere ad A le fatture di B e viceversa.

Non puoi programmare con questa mentalita'. Gli errori possono capitare in qualunque situazione, volendola mettere cosi' allora anche con piu' database puoi sempre sbagliare il nome della tabella e mostrare i dati di un altro cliente. Progetta il tuo software con attenzione, fai dei test e il debug se necessario. E ovviamente usa un unico database.

[telegio]

Originariamente inviato da k.b
Non puoi programmare con questa mentalita'. Gli errori possono capitare in qualunque situazione, volendola mettere cosi' allora anche con piu' database puoi sempre sbagliare il nome della tabella e mostrare i dati di un altro cliente. Progetta il tuo software con attenzione, fai dei test e il debug se necessario. E ovviamente usa un unico database.

anzi, se "parametrizzi" tutto è moooolto più difficile sbagliare..

[Santino83_02]

Originariamente inviato da las
è evidente che basta una piccola distrazione nella scrittura di una query e corro il rischio di far vedere ad A le fatture di B e viceversa.

è evidente che una cosa del genere non deve accadere...

[las]

Intanto rigrazio tutti per i validi consigli, effettivamente facendo un bilancio costi/benefici i vantaggi di avere un unica applicazione sono troppi per fermarsi per quella che forse è solo una paranoia inutile

Originariamente inviato da k.b
Non puoi programmare con questa mentalita'. Gli errori possono capitare in qualunque situazione, volendola mettere cosi' allora anche con piu' database puoi sempre sbagliare il nome della tabella e mostrare i dati di un altro cliente. Progetta il tuo software con attenzione, fai dei test e il debug se necessario. E ovviamente usa un unico database.

Permettimi solo un piccolo appunto, con i DB separati è impossibile mostrare i dati di un cliente a un altro, a meno di non sbagliare nella classe di connessione al DB ..... ma in quel caso cambio lavoro. per il resto però hai perfettamente ragione, se penso agli errori non faccio niente per cui in effetti come ho già detto forse la mia era una paranoia inutile, vuol dire che sarà la spinta per prestare maggiore attenzione nella progettazione.

Originariamente inviato da Santino83_02
una domanda manco da porsi: 1 database. fatto bene.

ci ho riflettuto molto e alla fine anche a me pare che sia meglio farlo bene il DB

Comunque grazie ancora a tutti. ovviamente seguirò il consiglio (peraltro avevo già iniziato) e sviluppo tutto in un unico db e unica cartella script.