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:
- 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.
- 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.