Galen Charlton a écrit :
Hi,
I would like to create two new tables, old_issues and old_reserves, that would be used to store completed checkouts (issues) and hold requests (reserves). Similar to how tables like deleteditems function, whenever a checkout or hold request transaction is completed or canceled, the row representing it would be moved to old_issues or old_reserves respectively.
I believe doing this would have several advantages:
1. The issues and reserves tables would cease to grow indefinitely; instead, they would have only as many rows as needed for a library's peak number of transactions. It is my hope that this would improve performance, particularly when processing long hold queues.
2. It would become possible to add a unique key constraint on issues.itemnumber (as an item can be issued only once at a time). Similarly, it may become possible to add unique key constraints on reserves.
3. Some queries and joins would be simplified. Perl code and ad-hoc reports could rely on a conceptually simpler notion that if a row is present in issues or reserves, it represents a current or otherwise active transaction.
Could also be done via status notions. (And I believe that reserves requires better status management, and maybe issues and items too)
4. Koha administrators could safely archive or truncate the old_issues and old_reserves tables if they desire to remove or completely anonymize circulation history.
Thoughts? My comment : Really good Idea, even though I am not really keen on getting more and more tables without a good MCD. (There was one for 2.2 but it is not up to date for 3.0. Maybe QA manager should/has to do it ;).... ) But My Question : When ? When are you planning to do that ? Is this Vital for Koha 3.0 features ? Shouldn't this wait for 3.2 ?
-- Henri-Damien LAURENT