I’ve been taking a closer look at the object model for Categories and Category Combinations in Postgresql. While putting together the object model I noticed that the categoryoptioncombo table****is not dependent on any other table in the database, yet contains critical values that are also referenced in the datavalue table.
My questions is, why categoryoptioncombos? Why link a datavalue table row to a categoryoptioncomboid instead of a dataelementcategoryoptionid?
the categoryoptioncombo table is in fact very much part of the schema and has foreign keys from the categoryoptioncombos_categoryoptions and categorycombos_optioncombos join tables.
The point with category option combos is that we need a single foreign key in the datavalue table which links it to the category model - this because a data value can be linked to any number of category options and we cannot have a dynamic number of columns/foreign keys in the datavalue table to each of them. So the categoryoptioncombos represent a unique set of category options, allowing a single row in a single table to be linked to a data value.
regards,
Lars
···
On Mon, Aug 19, 2013 at 1:03 AM, Farai Mutero fmutero@gmail.com wrote:
Hi All
I’ve been taking a closer look at the object model for Categories and Category Combinations in Postgresql. While putting together the object model I noticed that the categoryoptioncombo table****is not dependent on any other table in the database, yet contains critical values that are also referenced in the datavalue table.
My questions is, why categoryoptioncombos? Why link a datavalue table row to a categoryoptioncomboid instead of a dataelementcategoryoptionid?