Design difficile con più associazioni tra due entità

Question

Design difficile con più associazioni tra due entità

#1 da (2 voti)
#2 da (1 voti)

1

Sto provando a progettare lo schema dei dati e l'api riposante per un caso specifico.

Nel mio sistema ho diversi utenti e diversi libri. Ogni libro può avere diversi utenti come autori e allo stesso tempo ogni utente può essere un autore di diversi libri.

Ora la parte difficile, gli utenti sono interessati ad avere un elenco dei loro libri e a far sapere al sistema che sono gli autori, ma è importante che possano anche mantenere privata questa associazione. Quindi un utente può essere l'autore di un libro ma non desidera rendere pubbliche queste informazioni.

Ora una prima soluzione può essere quella di replicare le informazioni dei libri per ogni autore e impostarle come private o pubbliche ma questo non è ciò che voglio. La mia idea era di utilizzare due associazioni nell'entità utente (libri, public_books) in cui il secondo è un sottoinsieme del primo.

Ma un altro problema si presenta con l'api riposante. Non sono sicuro di quale sia un buon modo per esporre questo tipo di dati.

Qualcosa di simile forse?

/users/:id/books

che restituisce un elenco di libri creati con un'ulteriore proprietà booleana ispublic?

Esiste un'idea migliore per gestire questa situazione secondo te?

EDIT: L'API REST deve restituire tutti i libri collegati all'utente e offrire un modo per distinguere tra libri pubblici e privati. Un utente può ovviamente vedere tutti i suoi libri, ma solo i libri pubblici degli altri utenti.

Un'altra cosa necessaria è la possibilità per un utente di cambiare lo stato di uno dei suoi libri. Un libro privato può diventare pubblico e viceversa.

rest database-design

posta heapOverflow 20.01.2016 - 15:30

fonte

2 risposte

Leggi altre domande sui tag rest database-design

Come trovare la causa di un'eccezione nel codice asincrono Dove iniettare la dipendenza richiesta da tutti gli implementatori di un'interfaccia?

score 2 · Answer 1

But another problem comes with the restful api. I'm not sure what is a good way to expose this kind of data.

In qualsiasi modo ti piaccia. REST non si preoccupa, a patto che lo stato dell'applicazione sia completamente catturato nell'ipermedia. In particolare, a REST non importa come si scrive l'URI.

La convenzione è esprimere la gerarchia nel percorso e filtrare nella query. Per il tuo caso, ciò potrebbe significare

/users/:id/books?public
/users/:id/books?private

o

/users/:id/books?visibility=public
/users/:id/books?visibility=private

In alternativa, puoi pensare al contesto dei dati - che cosa sta cercando di fare l'applicazione quando guarda queste raccolte di libri. Ad esempio, potresti decidere che ci dovrebbe essere una risorsa "profili"

/users/:id/profiles/private/books
/users/:id/profiles/public/books

O anche molti di questi - non c'è una regola che non ci deve essere più di un URI che restituisce una particolare rappresentazione dei dati. Hai solo bisogno di capire quanti diversi percorsi vuoi supportare.

score 1 · Answer 2

Every book can have several users as authors and at the same time every user can be an authors of several books.

Quindi hai una relazione n: m. Nessun problema, questo significa che avrai bisogno di una tabella di collegamenti che faccia riferimento a entrambe le entità.

they can also keep this association private

Ancora meno problemi: aggiungi visibilità come un altro attributo alla tabella di collegamento.

In quale formato esponi queste informazioni tramite REST è davvero una domanda diversa, e impossibile decidere senza conoscere meglio le tue esigenze.