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