Hi Paul, I thought I should add something about the branchcategories table. This was set up because HLT wanted Koha to distinguish between different types of branch: 1) the branch as a physical building. HLT have four branches in different towns. 2) branch as a physical location. This can be "Mending" or "Processing" which mean that the item is in the back room of the library. The "holdingbranch" field on the items table holds a branchcode that points at an actual physical branch, either an actual branch or in mending etc. This field changes often. 3) the branch as a collection of books. HLT divides up their collection into items that belong in at a particular library (physical branch) and should always go back to that branch, or "Circulating". Those are items that can move between different branches. The "homebranch" field on the items table holds a branchcode that points at the collection branch that the item belongs to. This field seldom changes. The idea with the branchcategories and branchrelations table was to provide a way of distinguishing programmatically between the various types of branches. The logic of circulations depends on the different types of branches. Im not sure that they way it is currently implemented is correct though. In hindsite, I think it would be better to have two tables, "branches" and "collections", (and even "libraries"). The current setup overloads the branches table a little too much, and the branchcategories and branchrelations tables represent an effort to get around that. If you drop those tables from the database it could break the code in the Circulations. I havnt had a look recently, so Im not sure how much it still depends on it. Moveover, HLT need to have some way of managing the different types of branches, so if you do drop it you might want to bear that in mind. Hope that is helpful, Finlay paul POULAIN wrote:

Chris Cormack wrote:

...

I hope this makes it somewhat clearer, and that I have explained it.

Rosalie may have some comments too.

Yes, it's clear. But the consequence is still not 100% clear : As the code does not manage those constraints, it's just a "reminder". So it could be dropped without harm am I right ? If we want to keep it, constraints should be added, but that's not in the scope of the 2.0.0 imho.