[Fwd: Re: [Koha-devel] branchcategories => what's done for ?]

[Finlay Thompson]

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.
>