Merge borrowers and deletedborrowers tables
Hi devs, I am sure the community has already discussed about that: I am wondering why do we have a borrowers and a deletedborrowers tables when a "delete" flag in the borrowers table could do the trick. I am sure it's a matter of optimizing the sql queries, but did someone already compare on a descent database? It would help a lot to have the foreign keys set on other tables, to display the data if the library wants to displayed them. See bugs 13534 13668 14849 Doing this way, we make the DB structure consistent, but we will lost info. Cheers, Jonathan
Do not forget all cascaded updates and deletes. If you only set the flag, you will still need to perform those. What would be the big advantage of doing this?
I am wondering why do we have a borrowers and a deletedborrowers tables when a "delete" flag in the borrowers table could do the trick.
Some of the existing constraints are wrong, some does not exist. On the 3 bug reports (see original message), I have submitted patches to add/fix the FK constraint, but we will loose data. The big advantage is... not to loose these data :) For the major part of the existing foreign keys, we can keep them, even if the patron is "deleted". We will need to provide a script to really remove the patrons a library would want to delete. 2016-01-13 15:57 GMT+00:00 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:
Do not forget all cascaded updates and deletes. If you only set the flag, you will still need to perform those. What would be the big advantage of doing this?
I am wondering why do we have a borrowers and a deletedborrowers tables when a "delete" flag in the borrowers table could do the trick.
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/
I'm am totally in favor of merging borrowers and deletedborrowers! I think the same could be said for most if not all of the deleted/old tables. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jan 13, 2016 at 11:23 AM, Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
Some of the existing constraints are wrong, some does not exist. On the 3 bug reports (see original message), I have submitted patches to add/fix the FK constraint, but we will loose data. The big advantage is... not to loose these data :) For the major part of the existing foreign keys, we can keep them, even if the patron is "deleted". We will need to provide a script to really remove the patrons a library would want to delete.
2016-01-13 15:57 GMT+00:00 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:
Do not forget all cascaded updates and deletes. If you only set the flag, you will still need to perform those. What would be the big advantage of doing this?
I am wondering why do we have a borrowers and a deletedborrowers tables when a "delete" flag in the borrowers table could do the trick.
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/
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/
On Fri, Jan 15, 2016 at 8:53 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I'm am totally in favor of merging borrowers and deletedborrowers! I think the same could be said for most if not all of the deleted/old tables.
I couldn't +1 this more vigorously if I tried... I write a lot of reports for libraries, and I waste^H^H^H^H^Hspend more time writing clever coalesce statements in an effort to avoid MySQL's performance penalties for subqueries and unions... the results tend to be ugly and brittle. --Barton
Hi, On Wed, Jan 13, 2016 at 11:23 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
Some of the existing constraints are wrong, some does not exist. On the 3 bug reports (see original message), I have submitted patches to add/fix the FK constraint, but we will loose data. The big advantage is... not to loose these data :)
That is not an unambiguous advantage: one's "losing" patron data is another's "better protecting patron privacy". Also, merging the two tables will impose a cost on every user that has written reports that query the borrowers table and will be faced with the task of determining if they need to tack on "AND NOT deleted" clauses to the queries. That said, in Evergreen patron records do have a boolean flag that expresses logical deletion status. That approach has generally worked, but at the cost of requiring more code to fully delete and/or anonymize records for patrons who no longer have any relationship with the library. Overall, I'm neutral on the design question of using one table or two; I'm more dubious about the potential for disruption if we make a change, since we're not starting from scratch here. I note that the three bugs you've cited are concerned with the deletion of *staff* user accounts. A more minimal change might be to treat staff accounts specially and devise a way to mark them inactive instead of deleting them. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (5)
-
Barton Chittenden -
Galen Charlton -
Jonathan Druart -
Kyle Hall -
Marcel de Rooy