COmanage Developers List

[Scott Koranda <>]

> I think we'll probably want to discuss this on tomorrow's call, but
> here's a writeup of the options that have been proposed thus far:
> 
> [1] VARCHAR
> 
> This was my original proposal. Basically, each option gets a
> character representation, and each elected value gets encoded in the
> VARCHAR. For example, "race" has 5 possible values and so would be a
> VARCHAR(5). A person who identified as "asian" and "black" might be
> represented as "AB".

For the record we decided on option [1].

Scott

> 
> [2] INTEGER
> 
> Similar to VARCHAR, but using binary logic. Thus "asian" and "black"
> might be represented as 1|4 = 5.
> 
> [3] WIDE TABLE
> 
> Add one column per possible value. Thus
> 
>  INSERT INTO cm_demographics (co_person_id, race_asian, race_black)
>  VALUES (123, true, true);
> 
> [4] MANY-TO-MANY
> 
> Instead of having one table, we have one table per demographic type. Thus
> 
>  INSERT INTO cm_demographics_race (co_person_id, value)
>  VALUES (123, 'asian');
>  INSERT INTO cm_demographics_race (co_person_id, value)
>  VALUES (123, 'black');
> 
> In both cases [1] and [2], the model translates between the encoding
> and the view representation.
> 
> Note the cm_demographics wiki page is currently a hybrid of [1] and
> [2]. We'll need to fix that once we decide on a path.
> 
> Any other proposals to throw out there before we decide?
> 
> -Benn-