progettazione dell'abbonamento utente insieme all'abbonamento all'organizzazione esistente

1

Abbiamo un'implementazione esistente in cui tutti gli utenti appartengono a un'organizzazione dipenderà dalla sottoscrizione dell'organizzazione, quindi se l'abbonamento ha finito tutti gli utenti appartengono a questa organizzazione non sarà in grado di accedere alla nostra applicazione web. Non saranno in grado di accedere a causa dell'abbonamento scaduto.

Schema DB di esempio per implementazione esistente:

Ora vogliamo implementare un abbonamento non solo per un'organizzazione ma anche per singoli utenti. Quindi ci saranno:

Prova (per 1 utente e con accesso limitato ad alcune funzionalità) Abbonamento 1 (per 1 utente) Abbonamento 2 (per 20 utenti) Abbonamento 3 (questa è un'impresa e dipenderà dal numero di utenti consentiti di un'azienda). In questo modo devo tenere traccia degli utenti che sono in abbonamento di prova con la loro data di inizio e di fine, ma c'è anche un problema che questo utente di prova ha un'organizzazione che nell'organizzazione di implementazione esistente ha permesso gli account e la data di rinnovo (data di scadenza della loro sottoscrizione).

Sto pensando di creare una tabella di sottoscrizione in cui aggiungerò user_id e organisation_id in questa tabella e includerò la data di inizio e di fine anche il tipo di sottoscrizione indipendentemente dalla versione di prova, abbonamento 1, abbonamento 2 o abbonamento 3. Ma I ' m preoccupato che questa sarebbe una brutta implementazione sapendo che la tabella dell'organizzazione ha già permesso agli account (quanti utenti potrebbero accedere alla nostra applicazione web) e alla data di rinnovo (che è la loro data di scadenza della loro sottoscrizione). Qualche suggerimento su questo? Lo apprezzerei molto.

    
posta rpmansion 21.08.2016 - 11:03
fonte

1 risposta

1

Sto facendo supposizioni che potrebbero non essere vere sul tuo servizio.

Se il tuo servizio è implementato in un modo in cui a un'organizzazione viene assegnato il proprio URL o istanza del tuo servizio (ad es. http://myorg.yourservice.com ), puoi assegnare ad ogni abbonamento la propria istanza e non consentire ai dati di un abbonamento utente di mescolarsi con un altro abbonamento Tornando all'esempio nel mio commento, me.jpg sarebbe accessibile solo quando sono entrato in myusername.yourservice.com e _important_financial_stuff.xls_ è in myorg.yourservice.com . Non lasciare che i dati dei due abbonamenti si mescolino .

Per implementarlo, sostituirò gran parte di ciò che fa la tabella organisation con la tabella subscription che hai menzionato e aggiungo la tabella subscription_member . (Supponiamo che l'utente dall'esempio sia user.id = 2)

Subscription
| id | type | instance_name| start_date | end_date   | allowed_accounts |
----------------------------------------------------------------------- 
| 1  | org  | myorg        | 2016-08-01 | 2016-08-30 | 50               |
| 2  | sub1 | myuser       | 2016-08-01 | 2017-12-31 | 1                |


Subscription_Member
| subscription_id | user_id | user_type   |
------------------------------------------- 
| 1               | 2       | regular user|
| 2               | 2       | owner       |

Se tutti i tuoi dati / file / risorse sono collegati a subscription.id , sarà facile controllare l'accesso in base a se l'abbonamento è attivo o meno.

    
risposta data 24.08.2016 - 00:53
fonte

Leggi altre domande sui tag