Software in Cloud

[DavideDaSerra]

Se vuoi restare con un DB singolo, la cosa migliore è, per ogni tupla mantenere un identificativo dell' 'utente', però il software applicativo dovrà lavorare su 'viste', così che non ci sia il rischio che un cliente possa vedere dati dell'altro (la tabella 'vera' sarà accessibile solo al dbadmin). Oppure puoi fare più istanze del backend database (uno schema per cliente), così ogni applicativo 'cliente' ha il 'suo' schema (pur mantenendo un unica istanza del motore di database).

[elemet]

Se vuoi restare con un DB singolo, la cosa migliore è, per ogni tupla mantenere un identificativo dell' 'utente', però il software applicativo dovrà lavorare su 'viste',

Considerando il basso traffico di dati/accessi (almeno ad oggi) mi sembra un'ottima soluzione, semplice e veloce, MA

Oppure puoi fare più istanze del backend database (uno schema per cliente), così ogni applicativo 'cliente' ha il 'suo' schema (pur mantenendo un unica istanza del motore di database).

La vedo tecnicamente migliore, però mi sfuggono dei concetti forse per delle mie lacune di conoscenza...
Cioè significa che una stessa tabella la posso associare a diversi Schemi ? Quindi la tabella A che contiene i record dei clienti C1, C2,.... può essere segmentata (accessi alla tabella) automaticamente utilizzando diversi schemi ?
Scusami se non sono stato preciso o se ho detto una cavolata ma credo di non avere ben chiaro se è possibile associare una stessa tabella (stesso nome fisico) a diversi schemi, uno per ciascun cliente. poiché in tal caso facendo, ad esempio, una query verrebbe specificato il nome dello schema e la tabella ed il sistema tirerebbe fuori i record di quel cliente associato a quello schema. Giusto?

[aldofad]

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)

Assolutamente no, questo è contrario a ogni buon senso, oltre a violare le regole fondamentali di normalizzazione, di performance e di maintenance.
Deve esserti chiaro che cos'è uno schema/utente.
Devi creare uno schema (o chiamalo pure utente) per ogni cliente, ossia "create user CLIENTE_1 ..." "create user CLIENTE_2" ... ogni schema sarà strutturalmente una copia esatta degli altri.
Poi per ogni modifica strutturale ti genererai uno script di rilascio (e di no-go) appoggiandoti alle tabelle interne dei metadati, anche se avessi 1000 clienti non sarà un problema

[elemet]

Devi creare uno schema (o chiamalo pure utente) per ogni cliente, ossia "create user CLIENTE_1 ..." "create user CLIENTE_2" ... ogni schema sarà strutturalmente una copia esatta degli altri.

Quindi se ho capito bene, in riferimento agli esempi, ogni user (CLIENTE_1, CLIENTE_2.....) sarà amministratore delle tabelle A,B,C,D,E
Ovvero CLIENTE_1.A , CLIENTE_1.B , CLIENTE_1.C , CLIENTE_1.D , CLIENTE_1.E è uno schema e CLIENTE_1 è l'amministratore delle tabelle A,B,C,D,E per tale schema.
CLIENTE_2.A , CLIENTE_2.B , CLIENTE_2.C , CLIENTE_2.D , CLIENTE_2.E è un altro schema sulle stesse tabelle e CLIENTE_2 è l'amministratore delle tabelle A,B,C,D,E per tale schema.
Quindi le tabelle A,B,C,D,E sono strutturalmente le stesse ma i record al suo interno sono accessibili in base allo schema di accesso.
Quindi potrei (in maniera ridondante) in una tabella cui accede solo il sistema dove si associa lo schema all'account che si è connesso....
Esempio (account utente/password --> nome schema)
pippo/pippo1 --> CLIENTE_1,
pluto/pluto1 --> CLIENTE_2
Giusto?

[aldofad]

Quindi se ho capito bene, in riferimento agli esempi, ogni user (CLIENTE_1, CLIENTE_2.....) sarà amministratore delle tabelle A,B,C,D,E

Si chiama schema/utente/owner (in Oracle coincidono), l'amministratore sei tu ossia il DBA

Ovvero CLIENTE_1.A , CLIENTE_1.B , CLIENTE_1.C , CLIENTE_1.D , CLIENTE_1.E è uno schema e CLIENTE_1 è l'amministratore delle tabelle A,B,C,D,E per tale schema.

No. CLIENTE_1 è lo schema/utente/owner. CLIENTE_1.A identifica l'oggetto A (magari una tabella) di CLIENT_1. L'amministratore si chiama DBA è sei tu.

CLIENTE_2.A , CLIENTE_2.B , CLIENTE_2.C , CLIENTE_2.D , CLIENTE_2.E è un altro schema sulle stesse tabelle e CLIENTE_2 è l'amministratore delle tabelle A,B,C,D,E per tale schema.

Come sopra. Forse avevi capito ma usiamo la terminologia corretta

Quindi le tabelle A,B,C,D,E sono strutturalmente le stesse ma i record al suo interno sono accessibili in base allo schema di accesso.

Corretto.

Quindi potrei (in maniera ridondante) in una tabella cui accede solo il sistema dove si associa lo schema all'account che si è connesso....
Esempio (account utente/password --> nome schema)
pippo/pippo1 --> CLIENTE_1,
pluto/pluto1 --> CLIENTE_2
Giusto?

Si ma non chiamarla ridondanza, quella è un'altra cosa.

In questo modo (che è quello corretto, scusa l'assolutismo) ottieni tanti vantaggi di cui ancora non ti puoi rendere conto, se la discussione prosegue te ne elenco un po'

[elemet]

Si chiama schema/utente/owner (in Oracle coincidono), l'amministratore sei tu ossia il DBA

elemet ha scritto:
Ovvero CLIENTE_1.A , CLIENTE_1.B , CLIENTE_1.C , CLIENTE_1.D , CLIENTE_1.E è uno schema e CLIENTE_1 è l'amministratore delle tabelle A,B,C,D,E per tale schema.

No. CLIENTE_1 è lo schema/utente/owner. CLIENTE_1.A identifica l'oggetto A (magari una tabella) di CLIENT_1. L'amministratore si chiama DBA è sei tu.

-->OK perfetto, Grazie

Forse avevi capito ma usiamo la terminologia corretta

Giusto

Grazie sei stato chiarissimo

[DavideDaSerra]

[...]
Scusami se non sono stato preciso o se ho detto una cavolata ma credo di non avere ben chiaro se è possibile associare una stessa tabella (stesso nome fisico) a diversi schemi, uno per ciascun cliente. poiché in tal caso facendo, ad esempio, una query verrebbe specificato il nome dello schema e la tabella ed il sistema tirerebbe fuori i record di quel cliente associato a quello schema. Giusto?

Tu fai uno schema (tabelle nuove) per ogni 'utente'. Avrai schema cliente_1 con le sue tabelle, schema cliente_2 con le sue tabelle. Lo spazio utilizzato in questo modo è simile ma non c'è interdipendenza. In questo caso dovrai avere altrove un mapping utente-finale -> utente-del-database-specifico. NOTA: questo mapping può anche essere un 1-a-1 tra utenti del sistema e utenti del DB [come credo ti stiano suggerendo]. Per ogni nuovo utente crei un nuovo utente DB coi Grant per le sole tabelle/viste di sua competenza.

In alternativa puoi avere uno schema ausiliario 'apposito' in cui conservi il mapping utente-database, al login interroghi questo schema per vedere a che DB devi collegarti, una volta che hai il dato 'rompi' questa connessione e ti colleghi al DB di interesse

[elemet]

Tu fai uno schema (tabelle nuove) per ogni 'utente'. Avrai schema cliente_1 con le sue tabelle, schema cliente_2 con le sue tabelle. Lo spazio utilizzato in questo modo è simile ma non c'è interdipendenza. In questo caso dovrai avere altrove un mapping utente-finale -> utente-del-database-specifico. NOTA: questo mapping può anche essere un 1-a-1 tra utenti del sistema e utenti del DB [come credo ti stiano suggerendo]. Per ogni nuovo utente crei un nuovo utente DB coi Grant per le sole tabelle/viste di sua competenza.

In alternativa puoi avere uno schema ausiliario 'apposito' in cui conservi il mapping utente-database, al login interroghi questo schema per vedere a che DB devi collegarti, una volta che hai il dato 'rompi' questa connessione e ti colleghi al DB di interesse

Il ragionamento "fila" è perfetto però credo ci sia un problema, se ho ben capito.

Ho fatto una veloce verifica. Ho creato 2 schemi gemelli in MySql (ciascuno schema con una sola tabella per semplicità che chiamo ora "A"). Ho usato PhpMyAdmin, il quale mi ha creato 2 strutture dati effettivamente gemelli, ognuno con i suoi record che ho inserito manualmente , qui riprendo la tua osservazione che "Lo spazio utilizzato in questo modo è simile ma non c'è interdipendenza."
In un altro schema (struttura) ho una tabella di trascodifica in cui c'è il mapping fra account e schema.
Per ritornare all'esempio mi connetto (con una pagina di login in php) il sistema capisce che per il cliente pippo/pippo1 è associato lo schema CLIENTE_1 --> faccio la select ed ottengo i dati della tabella A dello schema 1 . Analogamente per altro cliente avente account paperino/paperino1 -->il sistema riconosce che si tratta dello schema associato al CLIENTE_2 ed effettuando la solita select mi tira fuori i record sempre della tabella A ma relativi allo schema del CLIENTE_2 ..... mi sembra tutto OK
MA
Supponendo di prendere un hosting a pagamento, il numero di DB è limitato , es. 10 DB ove per 10 DB, con tale tecnica (1 schema ad 1 cliente registrato), dopo 10 attivazioni ho finito numero di DB a disposizione.
Mentre non avrei problemi con un server dedicato... ma i costi aumentano sensibilmente e forse, in fase di start-up inutilmente.....
Se così non è allora ho confuso il concetto di schema con quello di Database, oppure mi sfugge ancora qualcosa
....perché ho consumato 2 DB dei 10 che l'hosting mi mette a disposizione.... altrimenti mi sono perso qualcosa....
Scusate se sono stato poco chiaro o impreciso

[aldofad]

un db contiene più schemi/utenti, hai effettivamente verificato che in hosting paghi per schema/utente?

se così fosse anteponi il prefisso CLIENTE_X al nome di ogni tabella

posta un link al provider che diamo un'occhiata

[elemet]

un db contiene più schemi/utenti

Si giusto ma nel momento in cui creo uno schema automaticamente è come se accedessi ad un DB separato

Ho provato in locale con phpMyAdmin 4.6.5.2 e sul provider misterdomain.eu , idem su un free hosting http://www.freewebhostingarea.com

Forse sbaglio qualcosa. Non so avete qualche link sulla rete con tutorial in merito.
Grazie per la disponibilità