[Koha-devel] inflexible field types for call numbers

[robweir]

Hi all,

I'd like to address an issue that I think could limit Koha's acceptance as a
viable solution in certain parts of the world - specifically the current
database fields available for storing call number information. Since call
numbers are so vital for a library and because there are so many different
systems for assigning call numbers, I think it would be to our advantage to
to make Koha as flexible as possible to work as many call number systems as
possible.

I think what I'm proposing might only involve changing a couple field types
or adding a field or two. Since we need to write conversion scripts to move
data from V1.2.3 to V2.0, wouldn't this be the best time to tweak the
database fields?

The issue I'm confronting is that almost every library I'm familiar with
here in the USA uses call number labels on the spines of their books with
four or even sometimes five lines of call number information. The second
line is usually all numbers, but not always. So basically there is a need to
store four or five fields worth of alpha-numeric call number information
with each field containing up to 8 or 10 characters. In looking at the
current fields available for call numbers in the biblioitems table, I find
several are not flexible enough to store this kind of data because of their
field type or length. Specifically, itemtype is varchar(4), dewey is
double(8,6), subclass is char(3), and publicationyear is smallint(6). So
none of those fields is suitable for storing up 8 to 10 digits of
alpha-numeric call number information. Did I miss some other possible
fields, or what is a library with four fields of call number information
supposed to do?

Ideally, I think Koha should have five fields possibly of type varchar(10)
available for storing call number information. If dewey and subclass were
converted to varchar, that would provide two. Would making that conversion
break anything in the existing code? (I do see a number of FIXME comments
already in Search.pm about dewey being a string and not a floating point
number).

Are there any other existing fields that could be adapted for this purpose,
or would it hurt to add a couple field to the biblioitems table? What is the
classification field for? Once these fields are available for storing the
data, individual libraries could develope their own templates for displaying
the call number information in a format that matches the spine labels on
their books.

I would be interested to hear if anyone else has confronted this problem and
how they solved it. What is Nelsonville Library doing for their call
numbers? What call number systems are used in other parts of the world and
would this idea work for them?

Thanks, Rob