https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35625
--- Comment #14 from Katrin Fischer <katrin.fisc...@bsz-bw.de> --- So this feels no like we are trying to implement something like inheritance in the database. We have a "base" ticket table and we have an additional table for any specifics. I think I get the idea now. The idea is very similar to the illrequestattributes, more than to the patron_attributes. The patron_attributes implement limited functionality for workflows, while the illrequestattributes are the data storage for any additional data a backend might need to function properly. At the moment I believe we are thinking to unify the functionality of: * OPAC problem reports * Catalog concerns * <a third thing I don't manage to remember right now> As always there is pros and cons to everything. The problems I see with additional attributes in their key/value form are: * No FK constraints on database level. * No proper datatypes. We store everything as a varchar. This can complicate validation and reporting. * Ease of writing reports with all columns (libraries have repeatedly told me they find it hard) I think there is a use case here... but I am not totally persuaded yet that it's strong enough for the examples given. For the reasons mentioned above, I feel like at least biblio_id might be better off as a column allowing for FK etc. and easy joining with other tables. And logging it could be of some use for the problem reports too (a lot of opac-pages are "biblio record" based (detail, isbd, marc, request, article_request ...) and logging it could allow for interesting reporting) -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
