[Koha-devel] Bug 5670: Housebound Module

Marc Véron veron at veron.ch
Thu Sep 29 16:01:46 CEST 2016


+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 at 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/
>



More information about the Koha-devel mailing list