第一，存贮在什么地方不是什么问题。一般来说，可以允许管理员指定某个SQL数据库（不一定跟当前系统数据库在同一个SQL中），但为了节省数据库投入成本和管理成本，我觉得还是在同一个SQL数据库中开辟一个“日志库”即可。
第二，关键是找一个兼顾各种指标的库表结构——即所谓的字段。你如果仔细看当前系统的日志记录，应该可以看到每种数据操作类型的日志记录不尽相同，所以如果有心，可以归纳一个字段提取需求，以它形成一个“日志库中的表结构”。只要大家认为这个字段提取可以基本涵盖所需的操作查找、汇总统计即可。
第三，这个将操作日志记入“日志库”中，并不意味着要取消当前生成的“日志文件”方式。所以不用担心日志记录存贮在与数据所在同一个SQL数据库后，因数据库受损导致无法找到日志进行灾难恢复。何况，假如仅为了查询与汇总统计所需，“日志库”中的记录，有可能会有些取舍或不一定顺序存贮（比如按不同操作类型分表存贮，就不方便形成线性的顺序），所以也不容易实现顺序恢复的效果。
所以，假如我们把每条日志当成一条原始记录存贮进数据库中，并根据需求，提取相应的检索点字段，可能就是一个较好的解决方案——那么，关键是这些相应的检索点内容，你们认为需要有哪些呢？册条码、读者证条码、操作时间、操作者、操作类型（如有细分，则按操作子类型提取）是否就够？
无须担心那种编目、册登记等不涉及到读者的数据操作——如果不存在读者证条码，则该检索点为空即可。
彭老师的提取内容中，含有册记录路径和读者记录路径——我认为提取到了唯一性的册条码和读者证条码后，册记录路径和读者记录路径就可以据此找到，所以无须再提取后者。