+1 for a new table, called 'housebound_role' Marc Am 29.09.2016 um 13:28 schrieb Alex Sassmannshausen:
Hello,
Whilst putting finishing touches on Bug 5670 Housebound Readers Module, a discussion was started on the best way to handle database architecture for a part of the feature. Jonathan, who has been heavily involved in reviewing the patch series so far, quite rightly suggested we get some additional opinions.
You can read the discussion on the bug (it's quite old, the last few comments are probably most relevant), but as a summary (primarily of my perspective):
The housebound module relies on assigning one or two roles to patrons registered in Koha. Patrons can be 'deliverers' (delivering items to housebound patrons), 'choosers' (selecting items which can then be delivered by deliverers), or both.
The current implementation uses extended patron attributes, but I would agree that this implementation is probably sub-optimal for the use case of the Housebound module.
We are now debating whether it is better to add 2 new columns to the borrowers table (increasing the number of columns from 69 to 71), for the two new roles, or whether we should create a new table, called 'housebound_role' to go with 'housebound_profile' and 'housebound_visit', which consists of - borrower_id (foreign key to borrowers.borrowernumber) - deliverer (boolean) - chooser (boolean)
My personal feeling is that the latter approach is better for the following reasons: - Housebound module is an optional feature switched on in sysprefs. - For the sites that enable it, I would expect that only a small percentage of all registered patrons become volunteers
As a result, the housebound_role table will be empty for sites that have the feature disabled, and small for sites that have it enabled.
Going with the former approach will implicitly create values for every patron in the installation, even if the feature is switched off.
For future development, making changes to the housebound_role table would be less intrusive than making changes to the borrowers table.
Finally, from a data integrity perspective, I cannot see either approach being better or worse at this point: the foreign key constraint will ensure data integrity, and the table is normalized in either case (though I'm certainly not an expert in this area).
WDYT?
Best wishes,
Alex _______________________________________________ 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/