Sorry, that should be

Relationships
Field1 RecordID (Meaningless Identifier)
Field2 PersonID - points to Persons record of this person
Field3 RelativeType - 1 = Father; 2 = Mother, 3 = Brother, 4 = Sister
Field4 RelativeID - points to PersonID of relative
Primary Key = RecordID
Secondary Index on PersonID + RelativeType + RelativeID (Unique)

You should also include son/daughter in the relative type.

In Paradox, I would make PersonID and RecordID fields meaningless long
Integers, in a MS SQL database a GUID would be suitable. The RecordID
field identifies a unique relationship of one person to one other
person. You wouldn't necessarily use this in your logic but Paradox
requires a unique primary key to have secondary indexes. You could, of
course, have a primary key of PersonID + Relative Type + RelativeID as a
compound key.

It's the PersonID key in the Persons table that has a relationship to
the PersonsID field in the Relationships table (1 -->>M) via the
secondary index (this links all immediate relatives 1 generation up, one
down and one sideways), and the RelativeID field in the Relationships
table relates back (1 --> 1) to the PersonID of the relative via the key
of the Persons table.

Through recursion, you can step through the database up, sideways or
down for as many levels as you want.

MichaelR (AT) niemand (DOT) org wrote:


--
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email

Sorry, that should be

Relationships
Field1 RecordID (Meaningless Identifier)
Field2 PersonID - points to Persons record of this person
Field3 RelativeType - 1 = Father; 2 = Mother, 3 = Brother, 4 = Sister
Field4 RelativeID - points to PersonID of relative
Primary Key = RecordID
Secondary Index on PersonID + RelativeType + RelativeID (Unique)

You should also include son/daughter in the relative type.

In Paradox, I would make PersonID and RecordID fields meaningless long
Integers, in a MS SQL database a GUID would be suitable. The RecordID
field identifies a unique relationship of one person to one other
person. You wouldn't necessarily use this in your logic but Paradox
requires a unique primary key to have secondary indexes. You could, of
course, have a primary key of PersonID + Relative Type + RelativeID as a
compound key.

It's the PersonID key in the Persons table that has a relationship to
the PersonsID field in the Relationships table (1 -->>M) via the
secondary index (this links all immediate relatives 1 generation up, one
down and one sideways), and the RelativeID field in the Relationships
table relates back (1 --> 1) to the PersonID of the relative via the key
of the Persons table.

Through recursion, you can step through the database up, sideways or
down for as many levels as you want.

MichaelR (AT) niemand (DOT) org wrote:


--
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email

Sorry, that should be

Relationships
Field1 RecordID (Meaningless Identifier)
Field2 PersonID - points to Persons record of this person
Field3 RelativeType - 1 = Father; 2 = Mother, 3 = Brother, 4 = Sister
Field4 RelativeID - points to PersonID of relative
Primary Key = RecordID
Secondary Index on PersonID + RelativeType + RelativeID (Unique)

You should also include son/daughter in the relative type.

In Paradox, I would make PersonID and RecordID fields meaningless long
Integers, in a MS SQL database a GUID would be suitable. The RecordID
field identifies a unique relationship of one person to one other
person. You wouldn't necessarily use this in your logic but Paradox
requires a unique primary key to have secondary indexes. You could, of
course, have a primary key of PersonID + Relative Type + RelativeID as a
compound key.

It's the PersonID key in the Persons table that has a relationship to
the PersonsID field in the Relationships table (1 -->>M) via the
secondary index (this links all immediate relatives 1 generation up, one
down and one sideways), and the RelativeID field in the Relationships
table relates back (1 --> 1) to the PersonID of the relative via the key
of the Persons table.

Through recursion, you can step through the database up, sideways or
down for as many levels as you want.

MichaelR (AT) niemand (DOT) org wrote:


--
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email

Sorry, that should be

Relationships
Field1 RecordID (Meaningless Identifier)
Field2 PersonID - points to Persons record of this person
Field3 RelativeType - 1 = Father; 2 = Mother, 3 = Brother, 4 = Sister
Field4 RelativeID - points to PersonID of relative
Primary Key = RecordID
Secondary Index on PersonID + RelativeType + RelativeID (Unique)

You should also include son/daughter in the relative type.

In Paradox, I would make PersonID and RecordID fields meaningless long
Integers, in a MS SQL database a GUID would be suitable. The RecordID
field identifies a unique relationship of one person to one other
person. You wouldn't necessarily use this in your logic but Paradox
requires a unique primary key to have secondary indexes. You could, of
course, have a primary key of PersonID + Relative Type + RelativeID as a
compound key.

It's the PersonID key in the Persons table that has a relationship to
the PersonsID field in the Relationships table (1 -->>M) via the
secondary index (this links all immediate relatives 1 generation up, one
down and one sideways), and the RelativeID field in the Relationships
table relates back (1 --> 1) to the PersonID of the relative via the key
of the Persons table.

Through recursion, you can step through the database up, sideways or
down for as many levels as you want.

MichaelR (AT) niemand (DOT) org wrote:


--
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email