I've setup a Directus CMS project with 3 collections as follows:
Actors
Movies
TV Shows
I'd like to associate Movies and TV Shows with Actors in a multi-select ordered list. I've tried looking at the one-to-many relationship and some others and can't seem to figure out how to build this. Ideally I would like it to look roughly like:
Editing Actor record John Smith
Multi-select array (or possibly some other interface) that includes all TV Shows and Movies
All TV Shows and Movies are shown by in multi-select by field "Title" of which both collections have
User can check boxes for individual TV Shows or Movies and order them in the multi-select as they'd like.
Do I need an intermediary junction collection? Am I missing something obvious here?
From initial impressions Directus looks to be an awesome CMS!
you were on the right track, but the relationship type you are looking for is a "many-to-many" (or M2M). This is because a movie can have many actors, and actors can be in many movies.
You can see the Directus documentation for this relationship setup here:
https://docs.directus.io/guides/relationships.html#many-to-many
You will add two junction tables, something like actor_movies and actor_tv_shows, each with a schema like this:
id — The primary key of the relationship
actor_id — The foreign key that holds the actor id
movie_id — The foreign key that holds the movie id
Therefore, each record in these tables link an actor to a Movie or TV Show.
Related
I'm new to Graph Database world, i just started to learn neo4j.
For example. I have a list of all video and a list of user watched video. How do I write pattern to query a list of not watched video based on specifed user id ?
I assume that your labelled property model looks something like this:
Some nodes with label "USER" for the users
Some nodes with label "MOVIE" for the movies
Some Relations of type "Has_Watched" to indicate a user has seen the movie
Then you can do something like this:
MATCH (user:USER)
WHERE user.Id = $yourId
MATCH (movie:MOVIE)
WITH user, movie
MATCH (user)
WHERE IsEmpty((user)-[:HAS_WATCHED]->(movie))
RETURN movie
So basically you get your user by ID and you get all movies. Then you only look for the movies that are not connected via a relationship of type "HAS_WATCHED".
Let`s use the movie DB as an example.
If I would insert all people that worked on a movie in the DB, it would be difficult to find relationship names for everyone. Would it be a problem to have entities like: sound_designer, sound_engineer, set_designer, set_assistance, cable_guy, etc with the same relationship "WORKS_IN" to a Movie entity. Is it possible? Is it a good solution? Would I have problems? Are there alternatives?
Gabor's answer in the comments is a good one, there are no problems with nodes of differing labels having relationships of the same type to the same node.
Multi-labeling nodes with their role isn't a bad idea, however that assumes that a person's role is constant throughout the years captured by the graph, which may not hold true. Or rather, the labels would capture what roles they have been in their entire history, but what specific role they played within a particular movie is likely something you want as a property of the relationship itself, like a role property. Which might even be a list, if a person might have multiple roles for the same movie, similar to actors playing a part (where there is a roles list property on :ACTED_IN relationships).
I'm trying to design a Neo4j graph database, and I will illustrate my specific requirement. I'm designing an app that allows users to collaborate on the books and magazines they have read. Requirements:
The same Book can be read by multiple people
The order in which a specific person reads the books is important. For example, I want to be able to represent that Person A read Books B1 and B2 in that order, while Person B may have read Books B3, B2 and B1 in that order.
I'm thinking of having nodes representing a Book, Magazine, Person, etc.
What is the best way to ensure the order/sequence information? A couple of options I thought about:
Store a order ID or timestamp in the relationship between a Person and a Book node and use that to query all Books read by the person in the right order.
Store a Next/Previous relationship between Book nodes, but this approach will not work because the order can vary depending on which person read the books.
To me this is the way to go, easy and effective.
Store a order ID or timestamp in the relationship between a Person and
a Book node and use that to query all Books read by the person in the
right order.
Storing a Next/Previous relationship will not work, because you would have to save UserID in the NEXT relationship between books and that is just nonsense.
I am trying to understand the concept of ER modelling, but I do not yet succeed. I have designed the ER model about movie database, but I do not know wheather it is a good design and how to connect the entities:
between Actor and Film i want to say "actor can play in each film only once" and at the same time "many actors can play in many movies" -- is it 1 to 1 relation or many to many?
and HOW do we need to think about entities ans relations between them? relations to one user, one film, one actor, one director, or in general?
UPDATE: new question : should the relation between Director and Film be 1 to many or many to many? I want to say : "one director can have many films && many directors can have may films" ??
Think about it like this: There are many movies. There are many actors. It makes sense that you would only want to include each actor in a particular movie once, but otherwise you want to be able to "mix and match" the movies and actors to express the relationship.
Looking at your diagram, you don't seem to have any fields which express the relationship between Film and Actor - those lines need to match actual fields. Read up on foreign keys: http://en.wikipedia.org/wiki/Foreign_key
The relationship between Actor and Movie that you want is actually many-to-many. You can express this with a "join table" (you'd need to add this to your diagram).
Something like this would work:
FilmActor
-------
uidFilm
uidActor
And put a unique constraint on those two fields together so it can't be duplicated (i.e. the same Actor can't appear in a Film twice)
I need help creating an appropriate database structure that will allow me to dynamically create "fields" and "values". I plan on using the following 5 tables.
TraitCategories
Groups
TraitGroupings
People
TraitValues
TraitCategories table holds only categories (i.e. "fields") of traits -- i.e. hair color, height, etc. -- and the categories can be added/removed as desired.
Groups table holds ad hoc/dynamic group labels -- i.e. Asian, South American, etc.
TraitGroupings is the join table for TraitCategories and Groups
The People table will be linked to the Groups table via a foreign key and thus will be assigned various categories (fields) of traits by leveraging the relationship between the Groups and TraitCategories tables.
But the question is, how do I assign per person values to the trait categories/fields?
I was thinking of having each row in the TraitValues table contain person_id and trait_category_id so that there will be a relationship between the TraitValues table and both the People and TraitCategories tables. Does this approach make sense? Will this approach allow me to get trait categories and values via the People table?
You are describing a form of EAV.
I'm not sure how practical this is going to be for representing in Ruby, but in you case, the database model would look similar to this:
(Most non-key fields omitted, for brevity.)
Note how we abundantly use the identifying relationships. This is what lets us propagate GroupId down both sides of the "diamond-shaped" dependency, and merge it into a single field at the bottom, in TraitValue.
This is what ensures a person cannot have a trait, unless it is also listed for that person's group. For example, a person can have a "hair color" only if the person's group has the "hair color" as well.
BTW...
The People table will be linked to the TraitGroupings via a foreign key -- and thus will be assigned various categories (fields) of traits.
If People has a FK that directly references TraitGroupings, then a person can have at most one trait grouping and therefore at most one trait category. From the wording of your question, that desn't appear to be what you want.