No,
really, this is not a database design issue. It's about how to design my
objects to model the relationships:
One-to-many:
taxon ---> node
---> node
---> sequence
---> sequence
One-to-one:
node ---> taxon
One-to-one:
sequence ---> taxon
Such that I can do:
my @nodes = $taxon->get_nodes;
my @sequences = $taxon->get_sequences;
my $taxon = $node->get_taxon;
$taxon = $sequence->get_taxon;
...with an underlying architecture where the relationships automatically are bi-directional in an elegant way. For example:
$node->set_taxon( $taxon );
...might mean that the $node now holds a reference to $taxon, but the $taxon now also has to hold a reference to $node. So should I then do:
sub set_taxon {
my ( $node, $taxon ) = @_;
$node->{'_taxon'} = $taxon;
# check if taxon already knows about me
for my $known ( $taxon->get_nodes ) {
return $node if $known == $node;
}
$taxon->add_node( $node );
return $node;
}
...but then the
$taxon->add_node( $node ) sub would likewise need to check if $node already knows about $taxon, and if not make the link in the other direction - without recursing add infinitum. All in all, that's not elegant.
So my question was: should the link making be managed by a third object (some sort of manager), to which the set_whatever, add_whatever, get_whatever method calls are re-routed. Or should I do something else entirely?
My question is not addressed by database designs, raw sql code, or object-relational mappers. Thank you for your input, though. I'm looking for suggestions for design patterns to deal with bi-directional relationships between objects. I understand that the suggestion for MVC has something to do with the issue (but the term MVC is so polluted at this point it's not unambiguously obvious how to apply it - perhaps the 'C' is the link manager?), so greatshots I think got what I was talking about, and so did graff.
I apologize to all others if I've phrased things so poorly that I made you write about databases.