The different event types have differing amounts of related data.
On this basis alone I would select the multiple-table version as my baseline and only consider something different if the performance of this was insufficient and I could prove that an alternative arrangement was more performant.
A single optional date with meta-data embedded in the column name
is usually workable but if you then have a bunch of other columns with name like:
preparation_date, preparation_col1, preparation_col2, consumed_col1, consumed_col2, consumed_date
I would find that to be undesirable.
You may be able to put Table Inheritance to good use here...
I do not know (but doubt) if HOT optimization works when going from NULL to non-NULL since the former is stored in a bitmap while the later occupies normal relation space and thus the update would likely end up writing an entirely new record upon each event category recording.
David J.
