Looking for a node relationship solution

By seanmclucas on 10 Oct 2008 at 16:30 UTC

Still looking for a solution here. I need a sibling-sibling relationship not really a top-down relationship between nodes.

I have a patient node type that might have multiple research study nodes associated with it. The patient node also has multiple status nodes associated with it. I need to be able to draw a relationship between one of the patient's studies and one of the patient's statuses. Just in case this isn't clear I'll give an example. Patient A is enrolled in a Diabetes Study and his status for that study is "qualified", while his status for an asthma study that he participated in last year was "disqualified".

I could create another intermediary node to manage the relationships but that just seems messy. Is there any way to easily build in these relationships with CCK or another module like Node Family?

I've poked around the forums and found a few people running into similar problems, however, most of the threads were old and inactive so I thought I'd try my luck here...

Comments

Nodereference and fieldgroup

gpk commented 10 October 2008 at 18:42

Nodereference and fieldgroup (both included in default CCK install) plus one of the CCK taxonomy modules might get you there. Not sure if this will let you add an arbitrary number of "fieldgroups" to a given patient node on the fly; not sure if you need that anyway.

gpk
----
www.alexoria.co.uk

Yup, that's the catch. The

seanmclucas commented 10 October 2008 at 20:11

Yup, that's the catch. The client needs to be able to add an unlimited number of sub-records for each patient. I've poked around with nodereference and fieldgroup, and relativity module, but none of these work out of the box. KarenS was working on a multi-field module for D6 but I haven't been able to get it to work and I'm planning on using D5 anyways.

Looks like I'll have to write some custom module that allows the users to create multiple instanced of a particular fieldgroup for each patient? Not sure how this will work, or if it is the best solution anyways.

Another concern is orphaned nodes.

Ideally, there would be one node for each type of 'status' and one node for each type of 'study'. Each user could add an infinite number of 'study/status' relationships tied each 'patient' node.

"Status" sounds like some

gpk commented 10 October 2008 at 21:59

"Status" sounds like some sort of categorisation, so I'd probably use taxonomy for that.

You might want to have a look at the http://drupal.org/project/category module though it appears to have significant flaws still in 5.x.

Some CCK field type contrib modules do allow a "times N" type facility ... possibly there is a CCK module out there that lets you add additional field instances on the fly. It must be a common requirement - worth a trawl through the modules list ...

gpk
----
www.alexoria.co.uk

What about OG?

LeeHunter commented 23 October 2008 at 02:11

This might be a bit off the wall, but I was tinkering with a somewhat similar problem and was wondering whether Organic Groups might be a (somewhat weird) solution. By making each patient into a separate OG you could have access to one or more status content types and have an unlimited variety or quantity of related content (with some bonus features like events thrown in)

I'm not sure how the out-of-the-box search engine would work though, since content is going to be spread over different nodes. For example, if name is in the OG main node and the status is in a collection of separate nodes doing a search for "Bob rejected" would (I would guess) never show any results.

Actually relativity module

seanmclucas commented 31 October 2008 at 01:00

Actually relativity module worked out for me after all. I had to create an "patient-study-record" node that had a parent 'patient-node'.

The patient-study-record node had CCK node reference fields that pointed to study nodes, site nodes, etc.

All of the relationships work like they should. My only issue is importing the data into Drupal now. Programmaticly creating nodes is easy, except when a particular node has a node reference field....still working on a solution for this.

Using the relativity module

tracy_pilcher commented 8 July 2009 at 14:57

Hi,

I have installed the relativity module, but I am not sure how to use it.

I have 3 content types, 1 parent, 2 children (of the same parent). I set up the relationships in the module configuration. But I am not sure how to utilize these relationships.

Parent content type "Inventory":

id field
name
desc

Child 1 content type "Inventory IP"

id field
ip address field

Child 2 content type "Maint history"
id field
action_date
action_desc

So for each Inventory there can be many IP addresses and Maintenance events. They can be linked by the common id field.

This is so easy to do with php/mysql and I will end up doing a module for this functionality, but it seems a shame that something like this can't be done within the drupal interface.

It seems like Drupal is great for existing content types, like blogs or a simple content type. But it isn't good for relating one content type to another. So, you end up with a flat file database, rather than a normalized one.

_

WorldFallz commented 11 July 2009 at 19:05

I handle all my node relationships with nodereference and nodereferrer fields and the views module-- works great. I've also been adding nodereference_url and views_attach into the mix for added functionality.