Don't create records in the DynamicEvidenceDataAttribute table unless the value differs from the default value for that type

Currently, we insert records in the DynamicEvidenceDataAttribute table with null or empty values under the value column. For example, we have a dynamic evidence with 4 attributes. First two are mandatory and the remaining two are optional to create an evidence record for this evidence type. If a user doesn't populate the optional fields, still we see 4 records getting created under the DynamicEvidenceDataAttribute table. Two records indicate mandatory fields with values and the remaining two records have value field populated with the default value for the attribute type {null, 0, 0.0, '', etc...}.

We could avoid creating records for optional attributes with empty or null values. When the same evidence is displayed on the screen, the System could look at the corresponding version of the evidence definition (ETV) and infer the default values for optional attributes that we don't have records in the DynamicEvidenceDataAttribute table. When a user edits that evidence and adds data to the blank optional fields, we can create records in the DynamicEvidenceDataAttribute table.

Bottom line is we don't create records in the DynamicEvidenceDataAttribute table unless the value differs from the default value for that type.

Customers have indicated that this efficiency if successfully realised would lead to 40-50% reduction in storage needs for the DynamicEvidenceDataAttribute table which is one of the largest DB tables (See related PMR [34215,004,000|https:w3-01.sso.ibm.com/software/servdb/crm/secure/l3PmrRecord1.do?&pmrno=34215&bno=004&cno=000&createDate=O15/03/09&method=retrieveCRMWithDate]). This would have positive impact on archiving/cleanup tasks by reducing the time batch jobs run for as well as the need to provision large disk space for these tables, which can be replicated around many environments as well as backups.

Things to consider...
- Evidence evolution. Is it possible to evolve the ETV and get unexpectedly different results at different points in time by inferring the value from the ETV.
- Performance. Would there be any negative impact on performance when resolving evidence values in 2 different ways (try read, if fail, then infer value from ETV)