Chapter 4. Modeling and Refactoring Patterns
Now that you’ve mastered the principles of graph modeling, you’re ready to explore some other modeling patterns. You’ll learn to recognize when to apply these patterns and weigh their pros and cons. Sooner or later you’ll also need to refactor your graph as your use cases and model evolve, so the second half of this chapter takes you through refactoring patterns with a hands-on approach.
Hyperedges: N-way Relationships
There’s a new trend—everybody appears to be interested in covers of songs. ElectricHarmony wants to jump onto the bandwagon by introducing a new feature that helps listeners find covers of their favorite tracks easily. This feature should also help them discover if some of their favorite tracks are indeed covers—and, if so, who the original artist is. You find yourself at the whiteboard with the team once again to model this use case.
The most obvious way to start is like in Figure 4-1: by specifying whether the artist’s recording of the track is a cover or not on the ARTIST relationship to the Track.
Figure 4-1. Quantifying the ARTIST relationship to indicate whether the track is a cover or not
Good modeling practice involves revisiting existing use cases to see if your refactoring has impacted them (perhaps adversely). You immediately think back to a key use case—fetching the track artist. So far, ElectricHarmony has ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access