La stessa app Android che si collega a più database -concept

Question

La stessa app Android che si collega a più database -concept

#1 da (3 voti)

1

Sto cercando il metodo migliore per creare applicazioni connesse a diversi database basati sul client

Quindi in pratica si tratta di un modello multi-tenancy per un'app per Android (uso aziendale)

Distribuisci la stessa app a clienti diversi ma connettiti a database diversi per clienti diversi.

Le cose a cui pensavo sono le chiavi e per ogni cliente la chiave varia e un webservice corretto verrà contattato in base alla chiave (singoli servizi web per ogni cliente)?

Qualcuno ha fatto qualcosa di simile? Qual è il metodo migliore per avvicinarsi a questo. Grazie

android android-market

posta Rohith Nair 21.11.2014 - 12:11

fonte

1 risposta

Leggi altre domande sui tag android android-market

Come distribuire il software automaticamente su SSH? Un framework di simulazione è utile se sto testando un repository / database? [duplicare]

score 3 · Accepted Answer

In ogni caso è necessario un server API (webservice, REST o simile) per connettere la tua app Android al database. Supponendo che il tuo database sia disponibile attraverso tale API, ci sono due opzioni.

Progetta il database & server per servire più clienti ( multi-tenancy ). Con questo, l'API del server si aspetta che la selezione della titolarità avvenga su base per-richiesta (ad esempio un'intestazione HTTP o un attributo di query) o all'inizializzazione della sessione (ad es. Quando l'utente esegue l'accesso).

Esempio REST:
```
# get customers for tenant ABC
GET example.com/api/customer/?tenant=ABC
# create a new customer for tenant ABC
POST example.com/api/customer/?tenant=ABC
```
Ovviamente, il tuo server dovrà assicurarsi che i client possano accedere solo ai dati che sono autorizzati a fare. Invece di passare tenant come parametro di query, può anche essere passato come intestazione HTTP o impostato come parte della sessione.
Crea diversi endpoint dell'API, con ciascun endpoint che si connette a un altro database. In questo caso la tua app Android deve essere configurabile in qualche modo, ad es. richiedendo l'endpoint dell'API da utilizzare da (ad esempio) il server di accesso centrale.

Esempio:
```
# Request API endpoint to use
# we assume the configuration response to contain the apiUrl parameter
apiUrl = GET login.example.com/configuration/?user=XY
GET <apiUrl>/customer/
...
```
Il server eseguirà più endpoint, ad es. abc.example.com o xyz.example.com per i tenant ABC e XYZ, rispettivamente. Quindi le chiamate API effettive saranno simili a questa:
```
# get customers for tenant ABC 
GET abc.example.com/customer
# get customers for tenant XYZ
GET xyz.example.com/customer
```

Come sempre con le decisioni di ingegneria, ci sono un paio di compromessi da considerare:

Segretezza dei dati / segregazione v.s. efficienza operativa. La multi-tenancy è relativamente semplice da risolvere in un database (aggiungi un campo tenant o simile almeno alle tabelle core del tuo modello dati, o ogni tabella per quella materia). Gestire un database è più facile che gestirne molti. Tuttavia, in alcuni settori potrebbe essere necessario conservare i dati in database separati.
Vs. dichiarativa codice client esplicito. Nel primo esempio, il client dell'app deve essere a conoscenza del titolare effettivo che esegue per poter inviare i parametri corretti al server. Nel secondo esempio, tutto ciò che il client dell'app deve sapere è l'URL dell'endpoint a cui connettersi.

Si noti che anche il primo e il secondo esempio possono essere mescolati:

Nel secondo esempio, lo stesso database può essere utilizzato per diversi clienti. Per fare ciò, eseguire un server Web front-end che aggiunge un'intestazione titolare alla richiesta HTTP a seconda dell'endpoint dell'API.
Nel primo esempio, il server potrebbe instradare la richiesta a un altro database in base alla selezione del tenant. Alcuni framework rendono banale tale routing, ad es. Django ha un router di database integrato.