Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Location History Table #181
Initially posted here 5d26033
The location_history table is going to be an extremely large (EAV) like table. Currently we have two varchar(30) columns
Can we convert these to integers - using concept_id
i.e. instead of relationship_type, change to relationship_type_concept_id
Integers would be expected to lead to better performance, I think. Plus, it would achieve the same end-goal that the CDM WG wants to represents in this table.
@clairblacketer @gowthamrao @cgreich That was the plan for relationship_type (create a small vocabulary) and I agree it also makes sense for domain_id. This seems similar to the way domains are represented in the FACT_RELATIONSHIP table?
then it would be:
The question I remember during the proposal was whether or not we should include relationship_type_source_value.
@rtmill from the proposal it looks like there will only be four options for relationship_type_concept_id ('residence', 'work site', 'school', NULL) so I don't see the need for a *source_value field. We can always add it later if the use case comes up.
In terms of domain_concept_id, we will most likely be moving to table_concept_id instead as there are multiple tables with the same domain (visit_occurrence, visit_detail) which makes it tricky for other tables that reference domain, like COST. For now we will keep it as domain_id until a decision is made on 9/4.