The M:N relationship is pretty straightforward in pure OO design. You have anEpisode that references a collection with instances of Track. And each Track has a collection of episodes.
Of course this could be elaborated even further, and have an object like TrackPlay sitting in between of anEpisode and aTrack. This TrackPlay object could have extra information, like the timespan at which it was played, the date (although this could be delegated to the Episode itself). It doesn't happen much these days, but a billboard hit was played more than once, so with a TrackPlay you could log both plays and know when each one was played. So Episode "has many" TrackPlay TrackPlay "references" Episode and Track The Track could "has many" Episodes (and ask them for the TrackPlays of itself) or "has many" references TrackPlay. And you can make things even more elaborated, but I'd go for the "TrackPlay" (for the lack of a better name) path. Regards, Esteban A. Maringolo On Mon, Jun 10, 2019 at 9:21 AM sergio ruiz <sergio....@gmail.com> wrote: > > I am currently putting together a Seaside website for my radio show. I am > trying to figure out how to model the "has and belongs to many" relationships. > > Each episode can have many tracks, each of these tracks can belong to several > episodes. > I want to be able to present a listing of which episodes each track appears > in, and a listing of tracks for each episode. > > The approach I have seen on this is to create an intermediary object and > store a set of ids on this, but this seems a little clunky, and it seems like > there would be a clean way to do this. > Am I missing something? > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >
