signal_market_signal_for_sale table breaks naming pattern of event vs. cache tables

[iostat]

there appears to be an implied pattern in the table names of what the tables actually do. they generally fall into a hierarchy of raw_change -> contract_name_event_name -> table_of_cached_state_of_something.

For example:

   raw_change
    ^      ^
    |      |
    |     signal_token_tracked_token: primary key "event_id" references "raw_change"("event_id")
    |                ^
    |                |
    |                +------------------------------------------------------------------------------+
    |                                                                                               |
    +-- signal_token_transfer: primary key "event_id" references "raw_change"("event_id")           |
                   ^                                                                                |
                   |  +-----------------------------------------------------------------------------+
                   |  |
                  signal: "tracked_token" references "signal_token_tracked_token"("event_id")
                          "last_transfer" references "signal_token_transfer"("event_id")

signal_market_signal_for_sale by name and almost entirely by DDL appears to be an event table, but is actually used as both an event table and a cache table. I propose separating its cache behavior out into a cache table such as signals_for_sale, for clarity.

[IvantheTricourne]

I would assume that this would greatly affect how the event indexers are currently (i.e., they would insert into this table as well).