ElectroYou

Salve a tutti
Non se qualcuno di voi si è mai imbattuto in qualcosa del genere.
Ho un piccolo software fatto da me con pagine sviluppate in PHP e database in mysql già utilizzato in una rete locale.
L'intento è di utilizzare lo stesso software in Cloud, ovvero, l'applicazione dovrebbe risiedere su un hosting a pagamento come anche il database ma vorrei creare tante istanze del database per quanti sono i differenti "clienti".
Mi chiedo come posso mettere su una infrastruttura che funziona in questo modo. Inoltre se ad esempio creo una nuova tabella oppure aggiungo un nuovo campo in una tabella già esistente, come posso estendere la modifica a tutte le istanze di database presenti?
Oppure volendo utilizzare un server in hosting, quale software di gestione mi consente di manutenere tutti i database con le modifiche che vengono fatte, evitando di intervenire singolarmente su ciascuna istanza (ciascun database) già presente?
Grazie

Unico db con uno schema/utente per ogni cliente

elemet ha scritto:Vorrei creare tante istanze del database per quanti sono i differenti "clienti".

Non ha senso adesso data la situazione. Quando questa attività comincerà a renderti parecchio allora mi chiami che migriamo su Oracle 12c creando un container database con un pluggable per ogni cliente...

elemet ha scritto:Inoltre se ad esempio creo una nuova tabella oppure aggiungo un nuovo campo in una tabella già esistente, come posso estendere la modifica a tutte le istanze di database presenti?

ti fai uno script usando le tabelle di sistema dei metadati

aldofad ha scritto:Oracle 12c creando un container database con un pluggable per ogni cliente...

Oracle 12c è una mattanza fra spazio su disco, RAM e licenze....

aldofad ha scritto:ti fai uno script usando le tabelle di sistema dei metadati

Ma allora il concetto di "Software come servizio" come viene applicato per i portali ove già utilizzano queste piattaforme? -->Fanno ogni volta degli script che lanciano su ogni istanza?? mi sembra piuttosto "artigianale" come soluzione...

elemet ha scritto:Oracle 12c è una mattanza fra spazio su disco, RAM e licenze....

...e vite andate dei consulenti

elemet ha scritto:Fanno ogni volta degli script che lanciano su ogni istanza?? mi sembra piuttosto "artigianale" come soluzione...

proprio così, che ti aspetti? E inoltre devi anche preparare e testare in anticipo gli script di "no-go", ossia se poi qualcosa va storto e devi tornare al punto di prima. Poi dipende dalla finestra di disservizio che hai, dai service-level-agreements che hai stipulato con i clienti, se i backup sono a freddo o a caldo e di conseguenza un'eventuale restore in caso di gravi pastrocchi.
La manutenzione è proprio tutta artigianale, eccome

Ad ogni modo ti ringrazio per il tuo intervento,
Al momento proverò con l'adottare con questa soluzione:

aldofad ha scritto:Unico db con uno schema/utente per ogni cliente

aldofad ha scritto:...e vite andate dei consulenti

Ho già perso io delle "vite" per mettere su un'infrastruttura Oracle 12c di test.... è stato un bagno di sangue di tempo e bestemmie....

La soluzione di aldofad è buona, ma se il sw dovrà diffondersi molto valutadi riscriverlo sfruttando middleware cloud esistenti (AWS, GAE, ...) in questo modo sfrutti 'nativamente' tutti quei sistemi che ti consentono di avere elasticità e scalabilità. Altrimenti rischi di arrivare a un punto in cui devi 'migrare' alla nuova infrastruttura e, in quel caso, lo sforzo è titanico rispetto a partire da subito con la versione riscritta ad-hoc per il cloud.

Per 'inpratichirti' ti consiglio di provare con GAE, con cui puoi sfruttare il livello 'base' gratuito e pagheresti l'extra quota solo se usato effettivamente.

Ti ringrazio per i preziosi spunti e suggerimenti

DavideDaSerra ha scritto:La soluzione di aldofad è buona, ma se il sw dovrà diffondersi molto valutadi riscriverlo sfruttando middleware cloud esistenti (AWS, GAE, ...) in questo modo sfrutti 'nativamente' tutti quei sistemi che ti consentono di avere elasticità e scalabilità. Altrimenti rischi di arrivare a un punto in cui devi 'migrare' alla nuova infrastruttura e, in quel caso, lo sforzo è titanico rispetto a partire da subito con la versione riscritta ad-hoc per il cloud.

Per 'inpratichirti' ti consiglio di provare con GAE, con cui puoi sfruttare il livello 'base' gratuito e pagheresti l'extra quota solo se usato effettivamente.

Al momento vorrei testare la prima soluzione, nel mentre proverò anche ad impratichirmi con GAE,

aldofad ha scritto:Unico db con uno schema/utente per ogni cliente

Questo significa che se il sistema (software) utilizza ad esempio 5 tabelle, chiamate per semplicità A,B,C,D,E ci deve essere un campo per ciascuna tabella che memorizza il nome "schema/cliente" , esempio C1 (cliente 1).
Pertanto tutti i dati confluiscono nelle stesse tabelle ma i record sono segmentati ed indicizzati per questo campo "nome schema/utente"; E così via per tutte le tabelle A,B,C,D,E .....
Quindi un eventuale manutenzione sulle tabelle si fa una sola volta poiché le tabelle sono uniche sotto un unico DB .
Ho inteso bene ?
Ma se così è, non ho una segmentazione degli ambienti ed un eventuale Export dei dati deve sempre avvenire per questo campo che individua i dati di quel "cliente".
Oppure, ho inteso male e la soluzione è diversa ?
Grazie

dalla mia poca esperienza credo che non sia utile creare tabelle per ogni cliente, se devi ricercare qualche specifica comune a tutti sarà più impegnativo, certo che dipende anche da quanto spazio dovranno occupare le tabelle.

per il database ho sempre lavorato in locale, quindi non saprei dirti cosa è meglio in internet.

io ho usato in vecchio Microsoft Jet4, anche attraverso la rete e funziona, poi ho usato ADODB, che credo lavori anche in internet, poi ho usato SqlServerExpressCompact, (leggero e free), non so se lavora in rete ma va molto bene in locale.

Altri utenti sono certamente più esperti di me su questo, saluti.

lelerelele ha scritto:dalla mia poca esperienza credo che non sia utile creare tabelle per ogni cliente

No, le tabelle NON sono per cliente. Le tabelle sono uniche, sono i dati (record) che vengono segmentati per "cliente".

lelerelele ha scritto:certo che dipende anche da quanto spazio dovranno occupare le tabelle

Esatto perché se ipotizzo di avere tanti "clienti" i record nelle tabelle aumenterebbero a dismisura ed in tal caso opterei per una diversa soluzione.

lelerelele ha scritto:per il database ho sempre lavorato in locale, quindi non saprei dirti cosa è meglio in internet.

. poiché DB+Applicativo risiedono sul server, il tutto avviene "lato server", solo le richieste vengono gestite in "remoto"; Ma in tal caso credo che non cambia nulla ed il tutto dipende dalla connessione/traffico disponibile in updload (se non è così correggetemi)

In definitiva, l'intento sarebbe quello di ottimizzare la manutenzione sull'unico DB. Ad ogni modo c'è qualcosa che mi sfugge forse nella gestione di schema-tabelle che magari non ho inteso bene/non conosco... se qualcuno ha avuto esperienze in tal genere di attività magari può illuminarmi

Grazie

Secondo me la tecnica migliore è la singleton connection.

Non so quale sistema d persistenza delle informazioni tu usi, ma ad esempio, con hybernate, sotto Java, si instaura una sola singleton connecction tramite una classe driver al DB, e poi si fanno le varie istanze a questa classe, per evitare di aprire troppe connessioni al database, che è notoriamente lento.

A questo punto, hybernate si occupa di gestire la concorrenza per la persistenza delle informazioni, tu potrai aprire tante richieste con tutte le query SQL di cui hai bisogno, invocando non una diversa connessione al DB per ogni cliente, o per ogni esigenza, ma una diversa chiamata a quell'unica istanza singleton.

Ci penserà poi lei ad occuparsi di fare i vari update al database.

In questo modo, dopo che avrai preparato tutti i vari "statement" al DB, non dovrai più preoccuparti degli accessi concorrenti.

Saluti