...

Then of course you couldnt see if it was more popular with children or adults, or more often borrowed by institions or normal borrowers etc.

<snip>

If you need this information you can have a database table like the user table but without the actual identifying features when the book is returned you use that table to identify the borrower rather than the user table. Round the DOB to year of birth, address to suburb and you can still do most of your report writing. You might want to even wait until all books borrowed by a particular day have been returned and use the same anonymised record---then you can even still do "people who liked XXX also like YYY" features (collaborative recommendation/filtering).

This is true. Well if its feature thats needed by people, (anonymised data that is). I can certainly put it on the todo list. People could anonymise the data themselves by running something like update issues set borrowernumber=0 where returndate is not null; Thered be no way then you could match a borrower with a returned item. So short term fix you could run a cron job to anonymise your issues data each night, (or every 5 minutes even) Long term we can put it on the todo list, and we'll get an option to run with anonymised data into the configuration file Thanks Chris