KISS your Koha patron categories

A case study of applying the KISS principle to simplify and standardize 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

   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:

   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.


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]