[Koha-devel] Bug 5670: Housebound Module

[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