L TmpV2 table: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
Line 2: Line 2:


=== Entity–attribute–value model ===
=== Entity–attribute–value model ===
The data stored in this table is similar to the [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model], but with the twist that it has different fields for different data types. The design was chosen because it allows us to add a new item quickly without having to change our [[sending]] functionality. A nice side effect is efficient storage without the bloat of adding new fields to tables and of having to retain fields that are no longer used. Having said that, the structure is is not intuitive to people who have only encountered flat files or relational data before.  
The data stored in this table is similar to the [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model], but with the twist that it has different fields for different data types. We are not using a true EAV model because this wasn't designed as EAV, but a result of some legacy hardware PDAs that made a change in collection complicated to implement, and this meant it only had to be implemented once.  The design allows us to add a new item quickly without having to change our [[sending]] functionality. A nice side effect is efficient storage without the bloat of adding new fields to tables and of having to retain fields that are no longer used. Having said that, the structure is is not intuitive to people who have only encountered flat files or relational data before.  


The table has fields to accommodate dates, integers, reals/floating point variables, text or booleans. It can accommodate one of each of these per line, such that if two variables of the same data type are needed, two lines need to be entered. The table was set up this way to accommodate any possible combination of data, but this flexibility comes at the expense of some inefficiencies in data-entry.  
The table has fields to accommodate dates, integers, reals/floating point variables, text or booleans. It can accommodate one of each of these per line, such that if two variables of the same data type are needed, two lines need to be entered. The table was set up this way to accommodate any possible combination of data, but this flexibility comes at the expense of some inefficiencies in data-entry.  

Revision as of 14:35, 28 October 2021

L_TmpV2 table in CCMDB.accdb and Centralized_data.mdb contains data that is either intermittent or just not currently accommodated in the rest of the database. All data that is stored in this table can be found at Projects.

Entity–attribute–value model

The data stored in this table is similar to the Entity–attribute–value model, but with the twist that it has different fields for different data types. We are not using a true EAV model because this wasn't designed as EAV, but a result of some legacy hardware PDAs that made a change in collection complicated to implement, and this meant it only had to be implemented once. The design allows us to add a new item quickly without having to change our sending functionality. A nice side effect is efficient storage without the bloat of adding new fields to tables and of having to retain fields that are no longer used. Having said that, the structure is is not intuitive to people who have only encountered flat files or relational data before.

The table has fields to accommodate dates, integers, reals/floating point variables, text or booleans. It can accommodate one of each of these per line, such that if two variables of the same data type are needed, two lines need to be entered. The table was set up this way to accommodate any possible combination of data, but this flexibility comes at the expense of some inefficiencies in data-entry.


add/link to better documentation for the auto-generation of lines in this table when a new record is generated.

  • added: no added date
  • action: no action date
  • Cargo


  • Categories

It is linked to L_Log table by D_ID.

Data Structure

To see the most up-to-date data structure of this table, see most up-to-date CCMDB data.mdb in Regional Server\data\Master. The fields are used differently depending on project, see Projects for a list and the individual project pages for field usage.

Field Name position type description
Serial 1 Number unique identifier of patient
Site 2 dropdown-limited text Hospital where the patient was admitted
Location 3 dropdown-limited text Ward the patient was admitted to
collected 4 Date/Time date the variable was collected
Project 5 dropdown-limited text  
Item 6 Text Project-Item identifier
DtTm_var 7 Date/Time date/time variable collected, if needed
int_var 8 number integer variable, if collected
float_var 9 number float/real variable, if collected
bool_var 10 Yes/No boolean variable, if collected
comment_var 11 Text comment variable, if collected
Instruction 12 dropdown-limited text Instruction as given in the dropdown S_Tmp
data_sent 13 Date/Time Date/Time the patient was sent