I would like to be able to correlate records in a table in such a way that when I manually assign a relative item to another item both of them get updated and show each other as "relatives". Can anyone suggest a structure for that?

For example, in an ITEMS table,

I would have records, where ItemName would be:

Screw

Washer

Bolt

Hammer

ScrewDriver

Key

How could I manually set relatives to each other and be able to see each item's (excluding itself) "relatives" in a portal?

Edited July 21, 201015 yr by Guest

When you document families of items in your database...

Are the relationships completely symmetric?

One could consider the following to have an asymmetric association.

Hammer --> Nail

Screwdriver --> Screw

Whereas {bolt, washer, nut} could have a more equal relationship.

Are these families restricted to two entries {hammer, nail} or can they be three or more {bolt, washer, nut}?

Can one item be a member of more than one family?

{hammer, nail}

{hammer, screwdriver}

{nail, screw, bolt}

Do these relationships have names, e.g.

John Smith, Sr. --> (son) --> John Smith, Jr.

John Smith, Jr. --> (father) --> John Smith, Sr.

(fasteners) {nail, screw, bolt}

Edited July 21, 201015 yr by Guest

You may be looking at something like

ITEMS

-----

_kp_ITEM_id

Name

FAMILY

------

_kp_FAMILY_id

Name

FAMILY_MEMBER

-------------

_kf_FAMILY_id

_kf_ITEM_id

Well, concerning your questions:

-I'm not quite sure what a as/symmetric relationship is. (although it is a greek word - haha)

-The example I gave with bolts etc is entirely fictional.

-The related items are features inside an archaeological excavation, and thus freely attributable to any kind of relationship to each other.

-Families would usually be required to NOT have a specific name rather than to have one.

A family may contain an unlimited number of members.

-It would also be quite desirable to allow a single member to belong to more than one family.

Hope I'm not asking too much.

What all this is about is relating excavation elements to each other in order to allow further research of the finds that seem to belong to the same context, as well some other archaelogical jargon which I strongly feel I should not refer to (quite boring sometimes -) )

So, we re just talking about arbitrary linking of records to other records and thud form groups that do not have an explicit relationship like an undergoing hierarchy of some kind... just neighbouring (regarding the place of retrieval) features.

Families would usually be required to NOT have a specific name rather than to have one.

A family may contain an unlimited number of members.

-It would also be quite desirable to allow a single member to belong to more than one family.

Unlimited number of members.

An item can belong to more than one family.

There are no privileged relationships among members. Each is an equal peer to one another in these families.

These qualities describe the math concept called "sets" so I'll use that term. "Family" and "relationship" have too much conceptual baggage and can cause confusion.

I think the table arrangement I provided in my previous post will meet these goals. (You can rename Family to the more generic Set.)

The Name field for the Set is optional and is provided as a user convenience. When you are adding an item to a set, you will need to have a way to distinguish which set you are adding it to. Since an item can belong to more than one set, just picking a set containing the other item isn't enough. You'll either need to browse all of the members in the set to see if it is the right one or examine its name.

That's really how far I have gone by myself.

In terms of application logic (GUI-wise speaking), how would you solve it?

Because essentially what I was thinking of is: a way of selecting other items and press-a-button-to-link-to sort of logic,then those appearing inside a portal...

That's really how far I have gone by myself.

In terms of application logic (GUI-wise speaking), how would you solve it?

Because essentially what I was thinking of is: a way of selecting other items and press-a-button-to-link-to sort of logic,then those appearing inside a portal...

Doing portals and scripting is one way to do it, but I think a better way to go is to provide an "Add to Set" button and create a New Window in a controlled way (Disable User Abort) that provides a list of possible Sets. The user can examine the existing sets, filter the list with some criteria using a scripted Find (criteria in the Header part), cancel the interaction, or create a new Set if no current set fits the need.

When displaying the Sets in List view, you can display the internally assigned ID of the set, the (optional) set name, and the first few members of the set. You can set it up to display only records that do not already contain the Item (using Find).

Doing portals and scripting is one way to do it, but I think a better way to go is to provide an "Add to Set" button and create a New Window in a controlled way (Disable User Abort) that provides a list of possible Sets. The user can examine the existing sets, filter the list with some criteria using a scripted Find (criteria in the Header part), cancel the interaction, or create a new Set if no current set fits the need.

When displaying the Sets in List view, you can display the internally assigned ID of the set, the (optional) set name, and the first few members of the set. You can set it up to display only records that do not already contain the Item (using Find).

sounds like a good idea!

I'll give it a try and let you know if I'm stuck.

THANKS A LOT!!!