Advice for my DB design and how to handle null / measuring errors
(Others may disagree, but here goes...)

If you have a good "natural" PRIMARY KEY, use it.  In my own tables, I find that is the case about 2/3 of the time.

What makes it good?


Must be UNIQUE (since the PK is, by definition, unique)
Must never be NULL (again, a PK requirement)
'Composite' is OK, as with your example:  (appID, created)
If there are no (or few) secondary keys, then it should be "small".  This is because every secondary index implicitly includes the PK columns.
A 'natural' key is more efficient for scanning.
Since your queries might be WHERE appID = constant AND created BETWEEN..., this order is much better:  PRIMARY KEY(assId, created).


Don't use INT (4 bytes) when MEDIUMINT (3 bytes) will suffice; etc.  If the value is 0..50, then TINYINT UNSIGNED (1 byte) is better.

How did you store 10,00 in INT?  Perhaps you meant DECIMAL(8,2)?

Do not normalize anything you might want to do a range test on, such as price or created.  In general, don't normalize 'continuous' values.  Nor small values.  For example, it is hardly worth normalizing a 5-digit zip code to replace it with a 3-byte MEDIUMINT.