Hi Paul, Steve, Yeah you have understood correctly, and sorry Steve I did get the names of those fields on the items table wrong. To explain again: I suggest we replace the BRANCHES, BRANCHCATEGORIES and BRANCHRELATIONS tables with just two tables:
* creating a BRANCH table that lists the possibles locations for an item. The branch field should change often. * creating a COLLECTION table that lists the possibles collections for an item. The collection should not change (or very rarely).
Each will have a primary key that is stored on the items table in place of the HOMEBRANCH and HOLDINGBRANCH fields. The existing structure is a little cluncky and was about to get more complicated when I was attempting to resolve a problem for the Horowhenua Library. They have books that are in a Circulating collection that go around the various (physical) branches. They also have Permanant collections which are supposed always to be held at a particular branch. When one of these Permanent collection items is physically returned to a different branch they want a flag to appear on the computer telling them that it should be returned to its Home branch. However they dont want the flag to appear when the item is already at the correct branch (obviously). Thinking about how to solve this problem made me realise that Item Collections and Physical Branches are really very different concepts and that much of the complication I was having was due to the fact that we are using one table: BRANCHES, for both. Steve, does that help clarify? Let me know what you think. Finlay
finlay@katipo.co.nz a écrit:
I propose:
To replace the existing branch tables (branches, branchcategories, branchrelations) with two tables: branches and collections.
This does entail the rewriting existing code. However because I wrote most of that code I dont think it will be too difficult :-)
Although this seems like a drastic measure given the simplicity of the bug in question, I think that it will be better for koha.
If I understand and re-say what you propose : * creating a BRANCH table that lists the possibles locations for an item. The branch field should change often. * creating a COLLECTION table that lists the possibles collections for an item. The collection should not change (or very rarely).
If i'm right, i think it's a very good idea.