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

[Nicole Engard]

I would say that items.enumeration should still have the formatted version,
but I like the idea of splitting in the serials table.

Nicole

Sent from my Nexus 7 tablet.
Please excuse brevity and typos.
On Aug 9, 2012 3:41 AM, "Julian Maurice" <julian.maurice at biblibre.com>
wrote:

> 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
> ______________________________**_________________
> Koha-devel mailing list
> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.**org/ <http://bugs.koha-community.org/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120809/51e0214b/attachment.htm>