stupid parent/child question

[poetnabotl]

I have trouble distinguishing which table is the parent and which is the child. If I make two tables, Terminators and CyborgBodyParts (don't ask. -Skynet). A Terminator can have many CyborgBodyParts but a CyborgBodyPart only can belong to one Terminator. It would stand to reason that, in that relationship, Terminators is the parent. Which I can't really prove except that it seems like a parent would have many children and a child only have one parent.

But let's say we start reusing body parts from retired terminators and giving them to others. So now, because a cyborgBodyPart can belong to more than one Terminator, we create a join table, cleverly named TermPartsJoin. (Related to TerminatorID and CyborgBodyPartsID, allow creation of records on the TermPartsJoin side of the relationship. Terminators table has a value list of CyborgBodyPartsID, showing records from TermPartsJoin::CyborgBodyPartsID.) So, who's the parent table now? Are there two parents and the join is the child of both? Because the join is the only table with two offshoots, is that the parent?

I know it's a stupid question but I searched and didn't find an answer and I've always kinda wondered.

Thanks!

[Weetbicks]

Its complicated. TermPartsJoin was born of parents Terminator and CyborgBodyParts (mother and father). Each child in TermPartsJoin has a mother and a father.

 

BUT, both parents are cheating whores, and have fostered many children with other mothers and fathers. Its a sick sick world out there in the future, adultery is rampant.

 

Ahem... but honestly, I don't know the terminology, and I really don't think it matters. What matters is your first case was termed a one to many relationship, and the second scenario is a many to many relationship, accomplished using a join table. My guess is TermPartsJoin is the child in the second case, with two parents. So long as Terminator doesn't spit out a CyborgBodyPart child, and then have sex with it, marry it, and spit out a weird deformed TermPartsJoin freak child, I think its ok.

 

 

God I need a drink......no wait... I need to put down the drink...

[poetnabotl]

Its complicated. TermPartsJoin was born of parents Terminator and CyborgBodyParts (mother and father). Each child in TermPartsJoin has a mother and a father.

 

BUT, both parents are cheating whores, and have fostered many children with other mothers and fathers. Its a sick sick world out there in the future, adultery is rampant.

 

Ahem... but honestly, I don't know the terminology, and I really don't think it matters. What matters is your first case was termed a one to many relationship, and the second scenario is a many to many relationship, accomplished using a join table. My guess is TermPartsJoin is the child in the second case, with two parents. So long as Terminator doesn't spit out a CyborgBodyPart child, and then have sex with it, marry it, and spit out a weird deformed TermPartsJoin freak child, I think its ok.

 

 

God I need a drink......no wait... I need to put down the drink...

 

I'm glad I'm not the only one confused about this. I'm also glad I'm not the only one drinking at 2 in the afternoon. 'Course, you're probably in Melbourne or something, in which case I am the only one drinking at 2 in the afternoon. Don't tell my sponsor.

[poetnabotl]

Wow, you actually are in the part of the world. Wrong country, but close.

[Weetbicks]

lol, wel its only 9:30am here in New Zealand.... but alas no drinking just yet, perhaps I should tho. So you're making a terminator database? awesome!

[AHunter3]

Not all tables that are related are related in a parent-child fashion.

 

To me, parent-child implies that there are no child table records in existence that were not created explicitly as the child of a specific parent record which by definition had to exist prior to the child record's creation.

 

let's say we start reusing body parts from retired terminators and giving them to others.

 

You don't always need a join table in every situation where you could use one, either. In a case like this, all you need is a value list consisting of existing body part IDs so as to optionally select one when creating a (different) child of a (different) parent. Presumably you aren't going to be entering much additional new info about the body part, such that you'd need to be concerned about a redundant record, and you make the data fields that do exist do a lookup from the previous incarnation, if any, of the body part record via selfjoin of body part ID to itself. Reduces the complexity of the system when you don't really need a full-blown many-to-many architecture. (It's not like the same body part simultaneously has many different parent terminators using it, it's just being redeployed).

[poetnabotl]

(It's not like the same body part simultaneously has many different parent terminators using it, it's just being redeployed).

 

You're clearly not familiar with the new Siamese Terminator. They look ridiculous but they're impossible to sneak up on.