L TmpV2 table: Difference between revisions

Line 2:

=== 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.

@@ Line 2: / Line 2: @@
 === 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.