Node relationships, backwards or forward?

Question

I know node references are not as popular as entity references are, but I'm curious on backwards and forward relationships.

This is a use case I see someone doing.

Job < -- Job Application

2 content types, and the node reference in the Job application point to Job.

In reality, shouldn't Job be pointing to the Job applications?

2nd use case

Project --> Files

When you create a project, you attach files to it, most of the time files are known beforehand so additional ones after parent node creation would be unlikely.

This is the more "correct" way as I see it, a Project can "have many" files. I also notice it could be done in the reverse as well, a file could reference a project.

The whole idea of Many to one, one to many, and many to many relationships in Drupal using the node / entity references module really make me wonder.

With the project user case, you can use references dialog, and you can create children right then and there. Doing the reverse of that, creating a parent could be possible, but why would one do that?

I've watched many videos, and I can see people doing it both ways almost with no consistency. I almost get confused myself when thinking about this. I come from doing things where these relationships are a bit more defined, and the DB schema is setup as so.

So does it really matter which way you put the reference? Also is it bad to have 2 node reference each other? I noticed there is some back references modules etc, what use do these have outside of making it easier for views? Did they have provide any other practical uses? (I know views3 with the node reference module , back references work out of the box now). Does it really just come down to workflow and how it would be easiest to get the creation forms to have the experience you want?

If someone could clear this up for me, I would really appreciate it.

Answer 1

A one-to-many relationship (also in DB design) is typically created by referencing the parent from the child. In the Jobs/Job Applications case, this translates into a reference from Job Application to Job, not vice versa.

In the Project/File case, if each file can only belong to one project, then it's also a one-to-many relationship and so File should reference Project. This is definitely how it should be if we were designing database tables for those entities.

However, in terms of Drupal and node references and given this particular example, Files are almost like properties to the Project node. So I wouldn't be surprised to see Files referenced from Project in a multiple-value node reference field, just for convenience.