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 _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
