https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35625
--- Comment #15 from Pedro Amorim <[email protected]> --- Thanks for the input Katrin, these are fair points. > * No FK constraints on database level. I'm not sure what the relevant disadvantages of this apply here. Possibility for stuff like child rows without corresponding parent rows for example, this can (and should) be prevented by being enforced through code at the application level. > * No proper datatypes. We store everything as a varchar. This can complicate > validation and reporting. Datatypes (and validation) is another thing we should handle at application level imo for these use cases (related metadata tables). When adding a new additional_field/patron_attribute_type the user should also be able to specify its data type (text, number, currency, date, av_list, relationship, etc). This will require a overhaul to patron_attribute_types, yes, but an overhaul is already required anyway (merging additional_fields and patron_attribute_types). > * Ease of writing reports with all columns (libraries have repeatedly told > me they find it hard) It's already the case for additional_fields and patron_attribute_types, we're not introducing a new pattern in terms of ease (or lack thereof) of writing reports. This could possibly be mitigated by having a few more examples in the wiki people can copy off from? -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] 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/
