Comment 9 for bug 1777675

Regarding previous inventory data, I would imagine that it would be useful to be able to report on the inventory status of an item at any point in its past. That's certainly been a consideration in the previous rounds of discussion and planning. But that's secondary to my concerns about 1) making a more robust feature set harder to provide and 2) bloating the copy table with rarely used (if important) information. For example, if we provide an index over the workstation or scan time columns for reporting or search purposes, that will prevent HOT update (a postgres technology that reduces bloat and increases speed) of rows on the copy table when updating unindexed columns. The impact is small per row, but that table is one of the longest and most heavily updated tables we have, so the cumulative impact is high.

On an effort-related note, after having looked at the code, moving the two fields to a new table (along with a copy pointer and primary key), and even providing, say, an asset.last_copy_inventory view over the raw data to hide the history, should really be the work of maybe an hour. The logic doesn't need to change, just the specific syntax. I'm willing to make those changes if it comes to that.