I think that the primary key would be useful for Bug 9717 'localuse recorded for holds/transfers' -- we could record 'localuse' when the item is checked in, and then update the statistics record to 'holdcaptured' or 'transferred' if the check-in captures a hold or completes a branch transfer. The statistics table is *very* slow to join borrowers or items against, because borrowernumber and itemnumber are not indexed. It also caused a 12 hour run of updatedatabase on site that had a large statistics table, when running the upgrade that fixed bug 14598 (itemtype is not set on statistics by C4::Circulation::AddReturn). This occurred on the 16.06.00.039 update.
+1
I think sometimes it's really useful that the entries are not all 'NULLed' on deletion of an item, borrower or staff user. Especially with our current 2 table setup. I often have to dig in statistics and action_logs when "strange things" happen at the circulation desk. Maybe insted of a FK we could just add an index?
(In reply to Katrin Fischer from comment #2) > I think sometimes it's really useful that the entries are not all 'NULLed' > on deletion of an item, borrower or staff user. Especially with our current > 2 table setup. I often have to dig in statistics and action_logs when > "strange things" happen at the circulation desk. > > Maybe insted of a FK we could just add an index? Never got a reply here. Marking WONTFIX, please re-open if you disagree.
In this case I agree, I don't think I'd use a foreign key but I see no issue with adding indexes for performance.