Serve aiuto per modellare una relazione Utente / Progetto / Attività

Question

Serve aiuto per modellare una relazione Utente / Progetto / Attività

#1 da (1 voti)

1

Quindi sto creando un'applicazione per la gestione di progetti / attività molto semplice in Laravel 4 e non sono sicuro di come funzionerebbero queste relazioni. Ho un Project , Task e User modello. Un User può possedere un Project o essere un membro di Project . Un Task appartiene a User e a Project .

Qual è il modo migliore per definire la relazione User / Project ? Potrei avere una relazione molti a molti da User a Project e usare una tabella pivot project_user per associare i due. Se volevo determinare se un User possedesse il progetto, potrei aggiungere un campo a Project chiamato owner e popolarlo con l'id del User che lo ha creato. Questo sembra un po 'sbagliato, dal momento che questa relazione verrebbe normalmente modellata in un rapporto di proprietà?

Qualsiasi consiglio è molto apprezzato:)

php mvc relationships laravel

posta Iain 15.02.2014 - 15:40

fonte

1 risposta

Leggi altre domande sui tag php mvc relationships laravel

Buona strategia per implementare attività di elaborazione listener fornite dal database Utilizzo dei modelli di stima dei costi per prevedere i costi di sviluppo del software C #

score 1 · Answer 1

Come lo descrivi, Project e User hanno due relazioni. Uno per la proprietà e uno per l'appartenenza. Il primo è una relazione uno-a-molti, la seconda una relazione molti-a-molti.

Aggiungere il proprietario al progetto e riempirlo con l'id utente è semplicemente il modo di esprimere quella prima relazione come chiave esterna.

Se un proprietario deve appartenere al progetto anche come membro è una regola di business completamente diversa e probabilmente dovrebbe essere modellata come un vincolo sul campo del proprietario, o da un trigger che aggiunge il proprietario come primo membro immediatamente e aggiungendo vincoli per garantire che il proprietario non possa essere eliminato dalla tabella pivot di appartenenza.

Potresti aggiungere un flag "is_owner" alla tabella pivot, ma vorrei sconsigliarlo. Anche se rende più semplice applicare una regola del "proprietario deve essere membro" (se applicabile), è meno flessibile, sembra innaturale e ciò richiederebbe logiche / trigger per garantire che ci sia sempre un solo proprietario. Richiederebbe anche un join per capire chi sono i proprietari dei progetti, mentre con il campo proprietario sulla tabella dei progetti, questa è una query molto semplice.