views:

49

answers:

2

My application is CoreData based but they may be a common theory for all relational databases:

I have a Output-Input to-many relationship in my model. There are potentially an unlimited number of links under this relationship for each entity. What is the best way to identify a specific input or output?

The only way I have achieved this so far is to place an intermediate entity in the relationship that can hold an output and input name. Then an entity can cycle through its inputs/outputs to find the right relationship when required. Is there a better way?

Effectively I am trying to provide a generic entity that can have any number of relationships with other generic entity.

Apologies if my description isn't the clearest.

Edit in response to the answer below: Firstly thank you for your response. I certainly have a two-way too-many relationship in mind. But if a widget has 2 other widgets linked to its Inputs relationship what is the best way of determining which input is supplying, say, 'Age' or 'Years Service' when both may have this property but I'm only interested in a specific value from each?

A: 

There really is no better way if you want to be able to take full advantage of the conveniences of fast and efficient in-store querying. It's unclear what you're asking in your additional comments, which I suppose is why you haven't gotten any answers yet.

Keep in mind Core Data supports many-to-many relationships without a "join table."

If Widget has many Inputs or Outputs (which I suspect could be the same entity), then a many-to-many, two-way relationship (a relationship with an inverse, in Core Data parlance) between Widget and Input is all you need. Then all you need to do is see if your Input instance is in the Widget instance's -inputs or if a Widget instance is in the Input instance's -widgets.

Is that what you were looking for? If not, please try to clarify your question (by editing it, not by appending comments :-)).

Joshua Nozzi
+1  A: 

I'm as confused as Joshua - which tells me that it may be that you haven't got a clear picture of what you're trying to achieve or that it is somewhat complex (both?).

My best guess is that you have something like:

Entity Widget Attributes:

  • identifier

Relationships

  • outputWidgets <<->> Widget
  • inputWidgets <<->> Widget

(where as per standard a ->> is a to-many relationship and <<->> is a to-many relationship with a to-many reverse relationship).

So each widget will be storing the set of widgets that it has as outputs and the set of widgets it has as inputs.

Thus a specific widget maintains a set of inputWidgets and outputWidgets. Each of these relationships is also reversed so you can - for any of the widgets in the input or output - see that your widget is in their list of inputs or outputs.

This is bloody ugly though.

I think your question is how to achieve the above while labelling a relationship. You mention you want to have a string identifier (unique?) for each relationship.

You could do this via:

screengrab

Where you create a new widgetNamedRelationship for each double sided relationship. Note that I'm assuming that every relationship is double sided.

Then for each widget you have a set of named inputs and named outputs. This also allows for widgets to be attached to themselves but only of there are separate input and output busses.

So then for your example "age" in your implementation class for Widget instance called aWidget you'd have something like:

NSPredicate *agePredicate = [NSPredicate predicateWithFormat:@"name='age'"]; NSSet *ageInputs = [aWidget.inputs filteredSetUsingPredicate:agePredicate];

Have I understood the question?

Grumpy Chuck
Thank you for doing what I could not and expressing my own problem coherently. The solution you suggest is exactly how I have currently solved the issue. I agree that the arrangement is ugly and was therefor wondering if there was a more elegant solution. I expect that there is not, I am after all perhaps asking CoreData to behave in a way that it was not designed in order to take advantage of the convenience of the pre-made data store handling. Many thanks.
Deano