Connexion
KISS your Koha patron categories
KISS, an acronym for “keep it simple, stupid” or “keep it stupid simple”, is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. The phrase has been associated with aircraft engineer Kelly Johnson. Variations on the phrase include: “Keep it simple, silly”, “keep it short and simple”, “keep it simple and straightforward”, “keep it small and simple”, or “keep it stupid simple”. [1]
Earlier today we received a request to add a new SQL report to generate a list of all students with their email ids from the librarian at our client partner Sister Nivedita University. The request prima facie was simple. However, when we looked at the patron categories for students under Administration, the first reaction was “Uh oh!”.
Let me explain. There were 8 patron categories for students (of all types) and all these student patron categories had different mnemonic codes that were as follows:
| DIP | Diploma – 2 years |
| GNM-3 | General Nursing and Midwifery – 3 years |
| RS | Research scholar |
| SPG-2 | Student Postgraduate – 2 years |
| SPG-3 | Student Postgraduate – 3 years |
| SUG-3 | Student Undergraduate – 3 years |
| SUG-4 | Student Undergraduate – 4 years |
| SUG-5 | Student Undergraduate – 5 years |
Still, just to fulfill the service request, all we needed to do was to create an SQL query like
SELECT
cardnumber, firstname, surname, email
FROM borrowers
WHERE categorycode IN
('DIP', 'GNM-3', 'RS', 'SPG-2', 'SPG-3', 'SUG-3', 'SUG-4', 'SUG-5')
The ‘problem’
There was no way to know from the mnemonic values that all these codes designated a student patron category, as there was no uniform standardization of the values used for student categories. To put the problem in a perspective that library professionals will understand easily – e.g. if we saw a DDC class number that started with 004, we’ll immediately know that it belongs to “computer science“, but what if the computer science documents were marked out with numbers that did not denote computer science under DDC???
Further, if in the future, the library added another student patron category, the SQL report would need to be updated in order to give the correct output that will include members belonging to this newly added category.
The ‘solution’
Luckily the solution was both simple and straightforward. We had to standardize and re-code the student patron categories and update the affected patrons. To do that we prefixed every student patron category with “STD_“. And thus, the student patron categories became:
| STD_DIP2 | Diploma – 2 years |
| STD_GNM3 | General Nursing and Midwifery – 3 years |
| STD_RS | Research scholar |
| STD_PG2 | Student Postgraduate – 2 years |
| STD_PG3 | Student Postgraduate – 3 years |
| STD_UG3 | Student Undergraduate – 3 years |
| STD_UG4 | Student Undergraduate – 4 years |
| STD_UG5 | Student Undergraduate – 5 years |
This was followed by updating the categorycode in the borrowers table to reflect the new changes. As a result the SQL query became much simplified:
SELECT cardnumber, firstname, surname, email FROM borrowers WHERE categorycode LIKE 'STD_%'
If the library added a new student patron category in the future, all they would need to do is prefix the code with “STD_” and this query would continue to work without any change with this simple and straightforward update.
Legalese
This solution required us to directly access the production database with MySQL’s foreign key check turned off with SET FOREIGN_KEY_CHECKS=0;. If you get inspired to follow this, please ensure you have a complete database backup before you attempt this. And if by chance, you manage to mess it up or damage your database while attempting to do this, we are NOT responsible in any manner.
References [1] https://en.wikipedia.org/wiki/KISS_principle
