Tabelle separate rispetto a una tabella singola per utenti registrati tramite social

Naviga le tue risposte
-1

In un sito Web gli utenti possono registrarsi tramite diversi accessi social: ex Facebook, google, github ecc. oltre alla normale registrazione e-mail.

C'è una tabella utenti per archiviare questi utenti e inoltre è necessaria una mappatura per verificare se un utente proviene da accessi di terze parti o meno.

  1. Una soluzione per archiviare gli utenti può trovarsi in una tabella in cui il design è il seguente: id (int), provider_user_id (stringa), provider (stringa)

Id è l'ID utente interno nel tuo sistema provider_user_id è l'id dell'utente nel sistema del provider Il fornitore può essere facebook, google etc

  1. La seconda soluzione è mantenere tabelle separate, ad esempio: facebook_users e ce ne sono id (int) facebook_user_id (stringa)

Fai la stessa cosa per tutti i fornitori (una tabella per ciascuno).

Quale approccio ti piace di più e perché?

    
posta Kristi Jorgji 14.05.2018 - 11:52
fonte

1 risposta

2

Se hai bisogno di diversi tipi di dati da diversi provider di identità, quindi utilizza tabelle diverse. Se tutti i provider di identità ti forniscono lo stesso tipo di dati, puoi combinarli in un'unica tabella, ma non devi.

Nota che dovrai separare diversi tipi di meccanismi di identità in tabelle separate comunque : autenticazione basata su email / password in una tabella e provider di identità di terze parti in una o più altre tabelle.

Probabilmente consentirai a un utente di avere più metodi di accesso, ma al massimo un'identità per ciascun provider. Qui, le soluzioni differiscono nel modo in cui esprimi i tuoi vincoli.

  • Se utilizzi una tabella per provider, hai una relazione 1: 0..1 tra utenti e identità del provider.
  • Se unisci i provider in una singola tabella, hai una relazione 1: 0..N. La tabella del provider deve inoltre utilizzare una chiave composta (user_id, provider_id) per limitare gli utenti a un account associato da ciascun provider. (Suggerimento: utilizzare ID o enumerazioni per i provider, non nomi di stringhe!)

Questo tipo di aumento della complessità mi indurrebbe a utilizzare una tabella per provider. Probabilmente il tuo codice considera ogni provider come un meccanismo di accesso completamente separato, non come un meccanismo di accesso generico in cui i provider differiscono solo per il loro nome. Tuttavia, l'utilizzo di un'unica tabella per tutti i provider è anche una soluzione perfetta, se si progetta il modello di dati di conseguenza.

    
risposta data 15.05.2018 - 16:38
fonte

Leggi altre domande sui tag

Modello di dominio e funzionalità Crypter Come leggere una notazione di classe astratta UML