Like the "issues" field in the items table, there should be a field for "local_use" to keep the count of local uses. While this information is kept in the statistics table, it is a task to acquire, and if a library wants to keep bloat down on their tables, the statistics are pruned on a regular schedule, which means loss of valuable data. This counter would keep that valuable information in one field in each item record, rather than having a separate field for each instance in the statistics table. Unless it is vital to someone to know the exact moment a local use occurred, I am suggesting that this piece of information not be recorded in the statistics table any longer. This would significantly reduce the growth of the statistics table in general. Christopher
I think an option would be ok, but I am against removing it - the local use information in statistics will allow to look up the timeframe (local uses in the last x months, years...) which is useful information.
Perhaps a switch to turn the statistic on/off? But add the counter to the record.
Could work :)
I absolutely agree if would be handy to have a local use number in the record -- and then to show that number on moredetail.pl. But I also agree with Katrin that I don't see why we would remove those transactions from the statistics table.
Read the second paragraph. It addresses this question.
My feeling is that a simple counter loses meaning the longer you keep the data. What's better? 5 local uses in 10 years or 5 in one? With a simple counter, there is no way to tell. I think issues might give an indicator about 'use' of the book (when you might want to replace it), but not sure the local_use is interesting in the same way. That said, we could split the circulation log preference to not record. Is the size of the data in statistics really that much of an issue? I seem to remember that some libraries have kept their data without pruning ever and have to say we don't prune either and have some systems running for almost 10 years now. It's only used for statistics, so it doesn't slow anything down.
The bigger the system, the more data you have to sift through, and it can make reports very sluggish. I'd be fine if it were kept in the logs, if there were some mechanism that could prune the logs of items that are deleted, and the pruning could be fine tuned as needed.
I get a feeling that opinions on the stats tables vary wildly. As I said, I would not prune them, but only anonymize them if necessary. Having an idea about when something happened seems important to me. Having jobs with different options make sense. BTW: as far as I know it won't free space with MySQL if you delete lines. So that should not be a reason?
*** Bug 18668 has been marked as a duplicate of this bug. ***