Modellazione di database. Da molte a molte relazioni. Tabelle di collegamento

3

Considera una tabella di database per informazioni su utente come:

id, name, email

ora considera che ho un'altra tabella per video qualcosa come:

id, name, description, length

Diciamo che esiste una relazione molti a molti in base all'abbonamento. Ovviamente, per gestire la relazione devi creare una terza tabella di link user_video_link :

id, user_id, video_id

Suppongo che qualcuno modellerebbe la tabella utente con la classe di entità Utente e in modo simile la tabella video con Video classe entità e lasciare che il framework di persistenza del database gestisca la relazione tra di essi.

Ora considera questo, sorge l'esigenza che l'utente possa scegliere di non essere interessato a un determinato video. Dove potrei salvare queste informazioni per adattarle al meglio alla mia architettura? Non immagino che cambiare la struttura di base di utente o video possa fare qualsiasi cosa. Vediamo alcune opzioni con le tabelle di collegamento:

  1. Potrei creare un'altra tabella di link, qualcosa come dire user_uninterested_video_link :

id, user_id, video_id

che sembra la via da percorrere in base a come va l'intera architettura del sistema, ma poi di nuovo, ci deve essere un modo elegante, quindi questa domanda.

  1. Un altro modo che sembra allettante è quello di non creare un'altra tabella di link, come suggerito in 1., ma di creare un campo booleano nella tabella di collegamento originale come un flag che indica che l'utente non è interessato a un determinato video. Questo approccio sembra plausibile perché abbiamo un'opportunità con la tabella di collegamento per affinare la nostra presa su un particolare collegamento tra l'utente e un video, uno a uno, piuttosto che essere persi al quadro più ampio, la relazione molte a molte esistente. La mia tabella di link sarebbe qualcosa del tipo:

id, user_id, video_id, interested

Ma seguendo questo approccio, quello che vediamo è che quando si tratta di modellare le tabelle del database nelle nostre classi di entità, dobbiamo anche modellare la tabella dei collegamenti. Inoltre, quando viene fuori qualcosa di simile, iniziamo ad aggiungere campi alla tabella dei collegamenti e in qualche modo la tabella intesa come tabella di collegamento di base finisce per diventare la tabella che contiene ogni logica di business, qualcosa di una divinità di qualche tipo. Inoltre, diventiamo così dipendenti dallo schema del database per programmare che ogni volta che si verifica un cambiamento, dovremmo analizzarlo per implementare il cambiamento. L'uso di framework per la persistenza esce dalla finestra e iniziamo a modificare manualmente ogni bit del database. Detto questo, dobbiamo davvero?

Ci deve essere qualcosa che mi manca. Qualsiasi commento su questa domanda di un artigiano esperto sarebbe molto apprezzato. Per favore, illuminami. Namaste.

    
posta Bibek Khadka 03.03.2018 - 07:14
fonte

1 risposta

3

Ignoriamo il fatto che la tua soluzione 2 non è semanticamente equivalente alla prima (poiché consentirà solo di modellare lo stato interested per un utente che ha una sottoscrizione per quel particolare video). Invece, fammi rispondere direttamente al tuo ultimo paragrafo:

But by going with this approach, what we see is that when it comes to modelling the database tables into our entity classes, we have to model the link table as well.

Questo è corretto (e IMHO non è insolito).

Further, when something similar comes up, we start adding fields to the link table

Questo potrebbe succedere.

and somehow the table intended to be a basic link table ends up becoming the table that holds every business logic, something of a god table of some sort.

No. Quando hai requisiti aggiuntivi, devi aggiungerli da qualche parte nel posto giusto nel tuo modello dati, questo non ha nulla a che fare se il posto giusto è una tabella di link o da qualche altra parte. E se i tavoli diventano "troppo grandi" o iniziano a violare le regole di normalizzazione, a un certo punto nel tempo dovrai rifattenerli per non diventare "tavoli divini". Questo vale per qualsiasi tabella nel tuo sistema.

Also, we become so dependent on database schema to program that each time any change comes up, we'd have to go through it to implement the change.

Quando è necessario aggiungere un ulteriore requisito, è necessario modificare qualcosa nel sistema, questo è abbastanza ovvio. A volte ciò comporta modifiche allo schema del database, a volte no. A volte è possibile modellare un database in modo da mantenere il rischio di modifiche inferiori rispetto a una diversa modellazione. Ma non è né possibile né desiderabile azzerare tale rischio. Piuttosto, scopri le migrazioni dello schema e come queste transizioni possono essere gestite senza problemi con il set di strumenti scelto. Ci sono state tonnellate di domande qui poste su questo sito e su Stackoverflow su questo argomento.

The use of frameworks for persistence goes out the window and we start tweaking every bits of the database ourselves.

I framework di persistenza non eseguono alcuna modellazione di database per te. E le modifiche standard a un modello di dati che richiedono attributi o tabelle aggiuntivi dovrebbero essere gestibili nel contesto di qualsiasi quadro di persistenza ragionevole. Tali cambiamenti dovrebbero essere abbastanza ortogonali all'uso di tale quadro.

Il tuo esempio mostra una situazione in cui la funzione "generazione automatica della tabella di collegamento" del tuo framework preferito non può più essere utilizzata. Ma solo perché c'è una caratteristica minore del tuo framework non applicabile non significa che la struttura diventi improvvisamente inutile. Quel framework ha ancora 50 altre utili funzionalità. Dover modellare da solo le tabelle di collegamento non è un motivo valido per non utilizzare un framework di persistenza.

    
risposta data 03.03.2018 - 09:40
fonte

Leggi altre domande sui tag