2009-11-09 15 views
8

Sto imparando Rails creando un sito semplice in cui gli utenti possono creare articoli e commentare tali articoli. Ho una vista che elenca gli articoli e i commenti più recenti di un utente. Ora vorrei aggiungere i 'profili utente' in cui gli utenti possono inserire informazioni come posizione, età e una breve biografia. Mi chiedo se questo profilo debba essere un modello/risorsa separato (ho già molti campi nel mio modello utente perché sto usando Authlogic e molti dei suoi campi opzionali).Il profilo di un utente dovrebbe essere un modello separato?

Quali sono i pro e i contro dell'utilizzo di una risorsa separata?

+0

Vedi anche: http://softwareengineering.stackexchange.com/questions/241089/keep-user-and-user-profile-in-different-tables – Jon

risposta

2

Lo terrei separato. Non tutti i tuoi utenti vorranno compilare un profilo, quindi quelli sarebbero campi vuoti che si trovano nella tua tabella utente. Significa anche che puoi modificare i campi del profilo senza modificare la logica del tuo modello utente.

4
  • Pro: semplifica ogni modello
  • Contro: Gestire 2 in una volta è leggermente più difficile

Si tratta fondamentalmente verso il basso per quanto è grande l'utente e il profilo sono. Se l'utente ha 5 campi e il profilo 3, non ha senso. Ma se l'utente ha 12 campi e il profilo 20, allora dovresti assolutamente farlo.

+0

Perché dovresti "definirli" se tutti hanno un molti campi? – Aaron

0

Dipende dalla larghezza della tabella utente esistente. I database in genere hanno un limite al numero di byte che una casella può contenere. Se sei vicino a (o al di sopra del quale puoi fare di solito se hai molti campi con valori nulli) il limite, vorrei aggiungere una tabella con una relazione uno a uno per prestazioni migliori e meno di una probabilità di un record che improvvisamente non può essere inserito in quanto vi sono troppi dati per la dimensione della riga. Se non sei vicino al limite, aggiungi al tavolo esistente.

4

Penso che ti sarebbe meglio servire mettendo in un modello separato. Pensa a come i modelli corrispondono alle tabelle del database e come li leggi per i vari casi d'uso supportati dalla tua app.

Se un utente accede al proprio profilo solo una volta ogni tanto ma si accede frequentemente al modello Utente, è necessario renderlo definitivamente un oggetto separato con una relazione uno-a-uno. Se i dati del profilo sono necessari ogni volta che i dati dell'utente sono necessari, è possibile che desideri inserirli nella stessa tabella.

Forse la posizione è necessaria ogni volta che si visualizza l'utente (ad esempio su un commento che hanno lasciato), ma la biografia dovrebbe essere un modello diverso? Dovrai calcolare la ripartizione corretta, ma la regola generale è strutturare le cose in modo da non dover estrarre dati che non vengono utilizzati immediatamente.

4

Si consiglia di mantenere le colonne del profilo nel modello Utente per chiarezza e semplicità. Se scopri che stai utilizzando solo determinati campi, seleziona solo le colonne che ti servono utilizzando: seleziona.

Se in seguito si rileva che è necessaria una tabella separata per qualche motivo (ad esempio, un utente può avere più profili) non dovrebbe essere molto impegnativo dividerli.

Ho commesso l'errore di avere due tavoli e non mi ha comprato altro che ulteriore complessità.

+0

Ho avuto la stessa identica esperienza. – Aaron

3

Un utente "possiede" varie risorse sul tuo sito, come commenti, ecc. Se separi il profilo dall'utente, allora è solo un'altra risorsa. L'utente è statico, mentre il profilo cambierà di volta in volta.

Separandolo consentirebbe anche di mantenere facilmente una cronologia del profilo.

Problemi correlati