I have a Drupal site which lists businesses and client recommendations. 1 business may have 0 or more client recommendations. Clearly the foreign key is on the "parent" business record. In Drupal talk, the nodereference is on the business node.
However, getting Drupal to allow an end user to elegantly add a new nodereference is a challenge: there are a number of solutions ranging from "don't worry about it" to a lightbox/popup to add new nodereference values. There is, however, a really slick solution that involves putting the nodereference on the child record. It's a clever recipe with nodereference_url + views_attach that gives a beautiful end user experience: at the bottom of the "parent" record, you get an "Add Child Record" (whatever text you put), you fill out the "child" record, and you get redirected back to the "parent" with each new "child" showing below as output by your view!
Two great demos of it are at lullabot and mustardseed media:
http://www.lullabot.com/articles/photo-galleries-views-attach
http://mustardseedmedia.com/podcast/episode37
The big question is, in my simple application where a user needs to be able to submit this Business record together with any number of his own Client Recommendations, does it really matter that I'm putting the nodereference as a back-reference from what would normally be considered the child record? Am I selling my soul for the sake of the client (again)?
Comments
..and on further thought
Maybe the client/child record should have the business id on it. That actually makes more sense.
how has your implementation
how has your implementation progressed and satisfied your business logic?
I'd like to see a "Best Practices" conversation regarding normalized database considerations in Drupal - particularly Content Types / "unique fields" issues.