Entity–attribute–value model of the L Tmp V2 table: Difference between revisions
Ttenbergen (talk | contribs) No edit summary |
Ttenbergen (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
This page explains the data model we use to store data from [[Projects]] in the [[L TmpV2 table]]. | This page explains the data model we use to store data from [[Projects]] in the [[L TmpV2 table]]. See [[L TmpV2 table]] for how the data is actually structured and stored, and [[Setting up a new tmp project]] for how the [[s_tmp]] table is used to store related meta-data. | ||
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 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. | ||
See [[Dropdown-like user experience for tmp projects]] for a slightly different twist on using this model to encode data. | |||
== Related articles == | == Related articles == | ||
| Line 9: | Line 9: | ||
[[Category:Tmp Project Infrastructure]] | [[Category:Tmp Project Infrastructure]] | ||
[[Category: | [[Category:L_TmpV2 table]] | ||
Latest revision as of 22:30, 23 October 2025
This page explains the data model we use to store data from Projects in the L TmpV2 table. See L TmpV2 table for how the data is actually structured and stored, and Setting up a new tmp project for how the s_tmp table is used to store related meta-data.
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.
See Dropdown-like user experience for tmp projects for a slightly different twist on using this model to encode data.