X-Git-Url: http://www.average.org/gitweb/?p=pulsecounter.git;a=blobdiff_plain;f=DATABASE;h=b498c2a0182b8ec8872892ccb4d3988369c10c39;hp=4108c08647bdec12b033edf04e36d59eb5e6e6a4;hb=f6a4965a22830a74cfbcc9b0b549d71d976bf5cb;hpb=88d75c965a5e62e3de6a4b735ad6f39adf059ad8

diff --git a/DATABASE b/DATABASE
index 4108c08..b498c2a 100644
--- a/DATABASE
+++ b/DATABASE
@@ -57,3 +57,32 @@ mysql:
 +---------------------+-------+
 6 rows in set (0.00 sec)
 
+2015-12-20:
+
+After some playing with it, I think it is a mistake. One of my assumed
+goals was minimize carrying state along time. This is achieved in the
+`counter` table, but not in `adjustment` table. Namely, when you need to
+adjust before one or more later adjustments, you'd have to update the
+later adjustment records. Advantage of this approach is that you need
+to select just one row from the `adjustment` table in addition to the
+row of the `counter` table. Disadvantage is as stated above, departure
+from the "write only" principle.
+
+So I am changing the design to this:
+
+
+select timestamp, value+adj as value from
+  (select c.timestamp timestamp, c.value value, 
+		(select sum(value) from adjustment a
+			where a.timestamp <= c.timestamp
+		) adj from counter c
+  ) t;
+
+so every row in the `adjustment` table contains incremental offset,
+typically simply the last recorded value of the counter (unless some
+events where lost while the sensor was down). Select is potentially
+more expensive; given that I do not anticipate many adjustments this
+should not be a problem for a single-user setup. For "industrial
+size" setup, the problem is easily solved caching the result of the
+"summing" select.
+