Child record first?

[Daniel Shanahan]

Is it possible to create a child record before creating a parent record? I am trying to create a solution where a field in the parent record ("Date") is dependent on a field in the child record ("Date").

dan

[Genx]

Depends on what makes your parent record the child's parent... Unless you've got DNA there's no real proof is there

The child is only a child in one context, it can also be the parent of it's parent in a different context (it all depends on which side of the relationship you're looking, or what you're doing) so the question is irrelevant. So, let's say you're on the child record and you create the "parent" record -- well, you're not creating a parent record... you're creating a child record, and from the perspective of the child, the child is the parent (weird huh?).

But the answer to the question I think you actually wanted to ask is yes... just relate them via your date field and turn on allow creation of related records on both sides (if that's what you're asking).. If it's not, then a more descriptive question may be appropriate.

In terms of who is who's parent like i said, the question isn't relevant. If you turn on cascading delete in the child and the parent then if the child is deleted then the parent is deleted which means the remainder of the children of the parent are deleted.

I.e.

Parent/Child -> "Parent" -> All other children

But... that means that in that case, at the time of the deletion which triggered the deletion of the "parent", the child was the true parent ... despite the fact that it would be the parent's child if another child was deleted.

[comment]

To me there's a big difference between parent and child - from whichever perspective you choose to look at them:

If in one of the tables the matchfield value is required to be unique, then that table is the parent, and the other is the child. It also follows from this definition that the relationship must be one parent to many children.

There are several ways to create unique parent records for existing orphans (if that's the question).

One way would be to import the children into the parent table, with the parent matchfield defined as Unique, Validate Always.

Another way would be to loop through the child records, and set the parent matchfield to the child matchfield value (with the relationship allowing creation on the parent side). This could be speeded up by sorting the children and jumping directly to the next category - similar to Edoshin's Fast Summaries.

[Genx]

What about in the case of a one-one relationship, or equally in the case of a many-many relationship -- i.e. a join other than your basic equi-join.

Think, dates:

Left Side Relationship: Date Greater than equal to right side relationship.

Right Side Relationship: Well obviously the opposite so Date Lesser than equal to left side relationship...

How do you do determine which is the parent unless you do so at run time based on the current context? Okay, it is an equi-join in this case, but out of curiosity, what if it wasn't?

[comment]

Well, I didn't say that every relationship is a parent-child relationship. I only said that when there is one, it is clear which is the parent and which is the child. I haven't thought about this in a context of theta-joins, but I don't see why the same principle couldn't be applied.

[Genx]

but I don't see why the same principle couldn't be applied.

The principle of a unique parent? (sorry i'm not deliberately being annoying I think i may just be missing what your saying).

[comment]

Yes, sort of. I want to be careful formulating any rules here, because it's easy to miss some possible exception. But in general, the parent is the one where the matchfield is a primary key - or a candidate key, which in Filemaker is the same thing.

[Genx]

Well... okay, I'll admit that covers most scenario's, however what about where there isn't a unique key in either table, and the relationship is more loose (going back to theta relationships here).

For example, you have a table with 100 random numbers, and you have a table with 150 random numbers (some sort of extremely odd probability distribution). Now, if you created a greater than join i.e. 100numberstable::number > 150numberstable::number for the purpose of isolating the number of records in the secondary table (the context of which will be determined at run time)... i.e. You want to know the result from the 100 side and the 150 side depending on the layout you're on. (It's a horrible example I know)

[color:blue]EDIT: In relation to the one-one, wouldn't both records have to essentially be related via a unique field? And in a many-many neither can really be related via a unique field... that or if you're using a join-table, they both are.

On a related note, is there any form / level of relationship besides parent-child, child-parent and sibling-sibling?

Edited June 14, 2007 by Guest

[comment]

In your example (agreed, horrible), there is no parent and no child. Or you could say it depends on how you choose to look at it - IOW, what you said in your first post. I am not even sure the parent-child thing is formally defined as such.

But in a one-to-many relationship, I think it's common to refer to the one as the parent and the many as the children. [color:purple]EDIT: Conversely, if you're speaking about parent and child, I will assume you are speaking about a one-to-many relationship. This directionality is defined by the structure - not at runtime.

Edited June 14, 2007 by Guest

[Daniel Shanahan]

Thanks. This conversation is interesting and helpful. Admittedly, I could have been more explicit in my initial post, so my apologies for my brevity.

The solution I am working on is for a tour company. A client would sign up over the web and put in a date in which she/he wants to take the tour. The tour does not exist until a client makes a request. In other words, the client does not look at a list of dates that the tour is offered. Rather, the tour operator accomidates the client by creating a tour when one is requested. Therefore, every child record is initially orphaned.

Based on GenX's first reply, I made the date field the match field. A script populates the Parent record and almost everything is displayed in a portal on the Parent layout.

I have another question concerning this project but I will start another thread as it has to do with Ancho/Buoy (or "Squid") methodolgy.

Thanks for the responses to this post.

[Genx]

I think it's common to refer to the one as the parent and the many as the children. EDIT: Conversely, if you're speaking about parent and child, I will assume you are speaking about a one-to-many relationship.

Okey, I can agree with the above. Thanks for your input Michael :o