Sergio,
When you have a two-way relationship, one option is to keep duplicate
information and use it to go from one object to the others. The advantage is
rapid lookup, but the disadvantage is the need to update multiple places to
maintain consistency (as well as the space it takes).
Another option is to keep the relationship in only one place and then do a
search for the secondary relationship on each lookup. So, each episode has a
collection of tracks and the episode to tracks lookup is direct. If you have a
track and want to find the episodes, then you query each episode to see if it
includes that track. The advantage is simplicity of design and maintenance (the
internal structures are never inconsistent; wrong, maybe, but never
inconsistent!).
The disadvantage is extra time doing the lookup. But before you discount this
approach, ask yourself what performance penalty this will cost. How many
episodes? How many tracks? Do you have less than 10K of each? How many
milliseconds does it take to do a “brute-force” search? I strongly recommend:
* Make it work, [and only then]
* Make it right, [and only then, if really needed]
* Make it fast
Do the simplest thing that can possibly work, and that is to have one one set
of references. Don’t add complexity till you need it. Hide (encapsulate) the
implementation so you can change it later if needed.
Another approach is to use a tool that provides automatic references. GemStone
includes indexes that are managed by the system, so you can just ask the index
for all episodes that reference a track. You only update one data structure but
the system manages more.
James
> On Jun 10, 2019, at 5:20 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 <http://bit.ly/29z9fG0>
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com <http://www.codeandmusic.com/>
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
>
