Entity–attribute–value model of the L Tmp V2 table: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
Tag: New redirect
 
Tag: Removed redirect
 
Line 1: Line 1:
#redirect: [[L_TmpV2_table#Entity–attribute–value model]]
This page explains the data model we use to store data from [[Projects]] in the [[L TmpV2 table]].
 
The data stored in the [[L TmpV2 table]] follows a model 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 "Item" field implements a dropdown that will offer fields encoded in the [[s_tmp table]]. That table also provides links to the page on this wiki that documents a given project; this link is shown in our collection tool [[CCMDB.mdb]] so collectors can easily reference the instructions.
 
== [[Automatic Generation of TMP entries]] ==
To make it easier for collectors to know what [[projects]] are currently collected, starting entries for projects that require an entry for ''every'' profile (possibly at a given site/program) are automatically created at profile creation through [[Automatic Generation of TMP entries]].
 
== Related articles ==
{{Related Articles}}

Latest revision as of 14:51, 28 October 2021

This page explains the data model we use to store data from Projects in the L TmpV2 table.

The data stored in the L TmpV2 table follows a model 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 "Item" field implements a dropdown that will offer fields encoded in the s_tmp table. That table also provides links to the page on this wiki that documents a given project; this link is shown in our collection tool CCMDB.mdb so collectors can easily reference the instructions.

Automatic Generation of TMP entries

To make it easier for collectors to know what projects are currently collected, starting entries for projects that require an entry for every profile (possibly at a given site/program) are automatically created at profile creation through Automatic Generation of TMP entries.

Related articles

Related articles: