Domanda

Ho un'applicazione web freelance che consente agli utenti di registrarsi per gli eventi. Nel mio database, ho una tabella con l't_events_applicants t_events_applications.user_id colonna con un vincolo di chiave esterna collegata alla colonna t_users.user_id. Quindi questo significa solo gli utenti che si sono registrati con la mia applicazione web possono registrarsi per gli eventi della mia applicazione web.

Il mio cliente vorrebbe ora per consentire agli utenti non registrati, gli utenti che non dispongono di una voce nella mia tabella di t_user, per registrare gli eventi. Questi utenti non registrati devono solo fornire il proprio nome e indirizzo email per registrarsi per gli eventi.

Devo creare una tabella con il nome t_temporary_user colonne e-mail e poi rimuovere il vincolo fk t_events_applicants.user_id? O dovrei aggiungere utenti non registrati al tavolo t_user e quindi aggiungere una colonna chiamata t_user.type dove tipo può essere 'iscritto' o 'non registrato'?

Come faccio a decidere quale approccio per andare con?

Un sacco di volte, ho esitato con entrambi gli approcci. Mi chiedo: "E se in un secondo momento, un utente temporaneo è permesso di diventare un utente registrato completamente? Allora forse dovrei avere solo un tavolo t_user. Ma poi anche io non sentirsi bene con la memorizzazione di un sacco di utenti temporanei in t_user ".

È stato utile?

Soluzione

Would not che in fondo essere un ruolo?

Creare una tabella utenti, dare loro una serie di ruoli (molti a molti users_roles).
Nella tabella ruoli, si dovrebbe aggiungere un ruolo che permette la registrazione per eventi e ruoli per diversi diritti sul resto del tuo sito web.
In questo modo è facile per la promozione di eventi per soli utenti finali di tutti gli effetti gli utenti (aggiungere i ruoli corretti) e sarà possibile aggiungere altre cose in seguito (altri eventi, abbonamenti speciali, ecc).
Molto probabilmente si dispone già di un tale sistema in atto comunque ..

Altri suggerimenti

Vorrei andare con il secondo approccio: aggiungerli nella stessa tabella, ma con la colonna Tipo. Se si creano due tabelle utente, dovrete controllare sempre sia per trovare un utente, ecc Con due tavoli, come si dovrebbe avere un vincolo da parte dell'utente per qualcosa che creano? Keep it simple, sono un utente, solo un tipo diverso.

Se si dispone di un CreateDate o la data LastLogin negli utenti (o qualche altro) da tavolo, è possibile rimuovere gli utenti temporanei dopo un certo periodo di tempo.

Sembra che gli utenti registrati contro utenti non registrati è diventata una falsa distinzione visti i nuovi requisiti di sistema. Vorrei tenerli tutti insieme in un unico tavolo. Mantenere le informazioni di registrazione del sito in una tabella separata. Non hai nemmeno bisogno di una colonna di tipo nella tabella combinata in quanto è possibile determinare se l'utente è registrato con un JOIN al tavolo di registrazione del sito.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top