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. 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? Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
On 3/11/08, Galen Charlton <galen.charlton@liblime.com> wrote:
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.
Hi Galen This sounds like a great Idea to me. As long as things like borrower history know to look in the new table, it should be all good. Chris
On Mon, Mar 10, 2008 at 3:55 PM, Galen Charlton <galen.charlton@liblime.com> wrote:
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: ...
Thoughts?
An excellent idea. Regards, Chris -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
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
Hi, On Tue, Mar 11, 2008 at 10:28 AM, Henri-Damien LAURENT <laurenthdl@alinto.com> wrote:
My comment : Really good Idea, even though I am not really keen on getting more and more tables without a good MCD.
MCD? I don't recognize that acronym.
(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 ?
IMO, this should be done now, and I'm prepared to have patches done by tomorrow. I have observed at least one instance where Koha permitted more than one issue to be made for the same item, which a PK constraint on issues would have caught. There are already a number of blockers involving holds functionality that will require extensive work, and I expect that I will turn up more circulation bugs as I work through cleaning up holds. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
My comment : Really good Idea, even though I am not really keen on getting more and more tables without a good MCD.
MCD? I don't recognize that acronym.
Modèle Conceptuel de Données = conceptual model of data. It comes from 'Merise' terminology, Merise beeing a sort of UML. I second Henri-Damien: a DB schema should be welcomed.
Frédéric Demians a écrit :
My comment : Really good Idea, even though I am not really keen on getting more and more tables without a good MCD.
MCD? I don't recognize that acronym.
Modèle Conceptuel de Données = conceptual model of data. It comes from 'Merise' terminology, Merise beeing a sort of UML. I second Henri-Damien: a DB schema should be welcomed.
I am QA manager, this is why I told that this was QA manager task ;) .
Frédéric Demians wrote:
MCD? I don't recognize that acronym.
Modèle Conceptuel de Données = conceptual model of data. It comes from 'Merise' terminology, Merise beeing a sort of UML. I second Henri-Damien: a DB schema should be welcomed.
Data model. -rick -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor Anyone who says he won't resign four times, will. -- John Kenneth Galbraith
participants (6)
-
Chris Cormack -
Chris Nighswonger -
Frédéric Demians -
Galen Charlton -
Henri-Damien LAURENT -
Rick Welykochy