[Koha-devel] Serials Work RFC - Storing Enumeration Data

[Julian Maurice]

Le 08/08/2012 21:35, Kyle Hall a écrit :
> Hello All,
> I'm working with a library that is having problems running reports
> based on serials enumeration data, and I was hoping to get some
> feedback on an idea I have.
>
> Right now, we store the enumeration format in
> subscription.numberingmethod ( e.g. "Vol {X}, No {Y}, Issue {Z}" ).
> When the serial is received, the X, Y and Z are replaced with real
> values and this is stored in serials.serialseq and items.enumchron,
> I'm wondering if it would be better to store this data in separate
> columns instead.
>
> 1. Add columns x_description, y_description, and z_description to the
> table subscription. In the above example these would contain 'Vol',
> 'No', and 'Issue' respectively.
> 2. Add columns x_data, y_data and z_data to the table issues. So for
> "Vol 5, No 2, Issue 7", these columns would be 5, 2 and 7
> respectively.
> 3. Retrospectively parse subscription.numberingmethod into
> x_description, y_description, and z_description
> 4. Retrospectively parse serials.serialseq into x_data, y_data and z_data
>
> At this point, we could get rid of serials.serialseq, or we could keep
> it alongside this new data. I would lean toward keeping it as we
> cannot guarantee step 4 will work right, as a librarian can modify
> serials.serialseq by hand when receiving the item.
>
> The question is: is this a good idea, or a stupid idea?
>
> Please let me know either way!
>
> Thanks,
> Kyle
>

I think it's a good idea generally to store 'basic' informations that
could generate other informations, instead of storing only one generated
data that we can only use for displaying purposes.

But before starting working at this, please take a look at Bug 7688 (if
you haven't yet). It allow to store numbering pattern in database
instead of having them hard-coded. In particular, description of X, Y
and Z are stored (so 1st point is already done ;))

-- 
Julian Maurice <julian.maurice at biblibre.com>
BibLibre