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.
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@biblibre.com>
BibLibre
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/