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