Architettura, design del database, evitare un riferimento circolare

Question

Architettura, design del database, evitare un riferimento circolare

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

-1

Devo progettare un database in un'applicazione Rails, dove ho utenti (che possono accedere), aziende e lavori.

Ogni utente appartiene a un'azienda e ogni lavoro appartiene a un'azienda, quindi quando un utente effettua l'accesso, l'applicazione cerca la società e gli mostra il lavoro ogni assegnato alla sua azienda. Il diagramma è qui:

Tuttavia,c'èun'altraspecifica:inogniazienda,c'èunamministratoreemoltilavoratori.Solol'amministratorepuòvedereilognilavoroassegnatoaogniutentedellasuaazienda,mentreilavoratoripossonovederesoloillavorocheglièstatoassegnato:unlavoratorenonpuòvisualizzareillavoroassegnatoalsuocollega.

Eccolagrandedomanda:PossoaggiungereunnuovocampoallatabellaJobs,unachiaveesternachefariferimentoallatabellautente,cosìpossoteneretracciadiognilavorocheappartieneaunasocietàeancheall'utentecheèassegnatoaunlavorospecifico?Sochesitrattadiunriferimentocircolare,enonèunabuonapratica,manonriescoavederealcunaaltrasoluzioneaquestoproblema,enonsonoabbastanzasicurodeiproblemichepotreiottenereseseguoquestoapproccio.Eccoildiagrammadiquesta"soluzione" circolare.

EDIT#1

Molticolleghihannosuggeritomodimoltointelligentiperfornireruoli(amministratore,utente,manager,ecc.)agliutenti.Iommitedperchélamiaprincipalepreoccupazioneèlarelazionetraaziende,postidilavoroeutenti.Adognimodo,peresserepiùchiari,hoaggiornatoleimmaginiperincorporarelatabella"ruoli".

architecture database-design diagrams circular-dependency

posta Karl 09.05.2017 - 22:37

fonte

3 risposte

Leggi altre domande sui tag architecture database-design diagrams circular-dependency

Pattern per memorizzare le credenziali di accesso per un'app mobile basata sul Web [chiusa] Perchè usiamo collezioni mutevoli ma stringhe immutabili

score 1 · Answer 1

Penso che sia necessario modificare il progetto iniziale per facilitare ciò che si vuole fare. Si prega di controllare questo schema:

Quando il tuo utente effettua il login, controlli la tabella UsersAndCompanies. Quindi, si guardano gli UsersAndRoles per vedere quale tipo di permessi l'utente ha (ad esempio, admin, sola lettura, modifica, ecc.). Quindi, ti sposti per passare a Lavori e recuperare i lavori per una registrazione. Infine, si sposta su UsersAndJobs per ottenere i lavori per l'utente che ha effettuato l'accesso in base alle autorizzazioni.

Questo design consente di 1) assegnare più ruoli a un utente (ma capisco che non è la tua preoccupazione qui), 2) consentire più di un lavoro a un utente. Se hai più lavori che possono essere condivisi tra diverse aziende hai bisogno di un'altra tabella (ad esempio JobsAndCompanies) ma questa è una storia diversa

score 0 · Answer 2

Sono d'accordo con Satanicpuppy in linea di principio.

Tuttavia, come altra opzione, vorrei aggiungere una colonna alla tabella user chiamata type e quindi definire diversi tipi, uno essendo admin . Ciò aggiungerebbe maggiore flessibilità qualora tu (in futuro) avessi altri utenti con permessi o privilegi diversi.

Una tabella di riferimento sarebbe anche carina - > per definire il types . Ad esempio:

type (table)
id type_desc
1  user
2  admin
3  manager

score 0 · Answer 3

Sono dati utente , devono essere nella tabella utente. L'aggiunta di un'intera riga nella tabella del processo sta facendo un passo verso il basso in un percorso buio ... Cosa succede se aggiungono un nuovo tipo di amministratore che può vedere ogni lavoro avviato da un utente il cui id utente inizia con un 4 ... Quindi tu? avremo bisogno di un altro campo nella tabella dei lavori.

Lo stato di amministratore può essere aggiunto banalmente alla tabella utente.

SELECT * 
FROM jobs 
WHERE 
  (companies.id = jobs.company_id AND job.user_id = user.user_id) OR
  (companies.id = jobs.company_id AND user.admin = 1);