pchristodoulou
New Member
Hi, can someone please advise on the following?
Let's suppose we have a database which conforms to the following design:
A main table called FIBRE, where info regarding types of fibres is stored.
A secondary table called FIBREXAMPLES where info about certain examples of real examples is stored (where it was found etc).
FIBRE is parent to FIBREXAMPLES by a one-to-many relationship (FIBRE.PK_FibreID --> FIBREXAMPLE.FK_Fibre.ID).
At the same time, ValueList Table called FIBRE_UseTypes is used to store different types of Fibre uses.
Since every find can be attributed to have at least one type of use per case, it needs at possibly a many-to-many table, called e.g. FIBREUSES, connecting FIBRE_UseTypes and FIBREFIND.
But we also need to gather all of the different uses documented for each FIBREFIND to its corresponding general parent table FIBRE.
From my point of view this can be accomplished by a double key relationship between FIBREXAMPLES and FIBREUSES, where one key will equal to a unique ID of FIBREXAMPLE and at the same time a non-unique key from the same record (FK_FibreID), representing its relationship to FIBRE.
I suppose this would be implemented by linking FIBREEXAMPLE to FIBREUSES twice, one with each record's unique ID as well as with the foreign key it has from the FIBRE table.
Thus, it will be possible to directly query FIBREUSES from FIBRE to see all documented uses of this kind of FIBRE according to each separate FIBREXAMPLE.
Do you find this practice correct in Fabrik?
I am only considered regarding the data redundancy rising from the multiple instances of the same FIBRE ID in FIBREEXAMPLES.
Do you have any recomendations / objections / comments?
Let's suppose we have a database which conforms to the following design:
A main table called FIBRE, where info regarding types of fibres is stored.
A secondary table called FIBREXAMPLES where info about certain examples of real examples is stored (where it was found etc).
FIBRE is parent to FIBREXAMPLES by a one-to-many relationship (FIBRE.PK_FibreID --> FIBREXAMPLE.FK_Fibre.ID).
At the same time, ValueList Table called FIBRE_UseTypes is used to store different types of Fibre uses.
Since every find can be attributed to have at least one type of use per case, it needs at possibly a many-to-many table, called e.g. FIBREUSES, connecting FIBRE_UseTypes and FIBREFIND.
But we also need to gather all of the different uses documented for each FIBREFIND to its corresponding general parent table FIBRE.
From my point of view this can be accomplished by a double key relationship between FIBREXAMPLES and FIBREUSES, where one key will equal to a unique ID of FIBREXAMPLE and at the same time a non-unique key from the same record (FK_FibreID), representing its relationship to FIBRE.
I suppose this would be implemented by linking FIBREEXAMPLE to FIBREUSES twice, one with each record's unique ID as well as with the foreign key it has from the FIBRE table.
Thus, it will be possible to directly query FIBREUSES from FIBRE to see all documented uses of this kind of FIBRE according to each separate FIBREXAMPLE.
Do you find this practice correct in Fabrik?
I am only considered regarding the data redundancy rising from the multiple instances of the same FIBRE ID in FIBREEXAMPLES.
Do you have any recomendations / objections / comments?
