==========
以下是引用 孤舟蓑笠翁 于 2011-11-14 21:52:09 发表的文字:
第一，存贮在什么地方不是什么问题。一般来说，可以允许管理员指定某个SQL数据库（不一定跟当前系统数据库在同一个SQL中），但为了节省数据库投入成本和管理成本，我觉得还是在同一个SQL数据库中开辟一个“日志库”即可。
第二，关键是找一个兼顾各种指标的库表结构——即所谓的字段。你如果仔细看当前系统的日志记录，应该可以看到每种数据操作类型的日志记录不尽相同，所以如果有心，可以归纳一个字段提取需求，以它形成一个“日志库中的表结构”。只要大家认为这个字段提取可以基本涵盖所需的操作查找、汇总统计即可。
第三，这个将操作日志记入“日志库”中，并不意味着要取消当前生成的“日志文件”方式。所以不用担心日志记录存贮在与数据所在同一个SQL数据库后，因数据库受损导致无法找到日志进行灾难恢复。何况，假如仅为了查询与汇总统计所需，“日志库”中的记录，有可能会有些取舍或不一定顺序存贮（比如按不同操作类型分表存贮，就不方便形成线性的顺序），所以也不容易实现顺序恢复的效果。
所以，假如我们把每条日志当成一条原始记录存贮进数据库中，并根据需求，提取相应的检索点字段，可能就是一个较好的解决方案——那么，关键是这些相应的检索点内容，你们认为需要有哪些呢？册条码、读者证条码、操作时间、操作者、操作类型（如有细分，则按操作子类型提取）是否就够？
无须担心那种编目、册登记等不涉及到读者的数据操作——如果不存在读者证条码，则该检索点为空即可。
彭老师的提取内容中，含有册记录路径和读者记录路径——我认为提取到了唯一性的册条码和读者证条码后，册记录路径和读者记录路径就可以据此找到，所以无须再提取后者。
==========
这件事情提出来很有些日子了。
我觉得要避免两个极端的方向：
一个是认为日志库是万能的，需要什么信息在里面一检索就得到了。持有这个想法的朋友，多半是对数据库的能力和限制不了解导致的。目前的日志文件和日志记录结构，首先是为忠实描述日志信息而设计的，也就是说，它唯一的目的就是要保存好日志信息，在恢复的时候能完整恢复以前的信息。因为操作类型的复杂性，所以日志记录的格式非常复杂。这个复杂性不是我们开发者人为造成的，而是实际业务的复杂性导致的。
而，把全部日志记录集合起来成为一个“数据库”，那么其中的记录的格式就必须在某种程度上达成统一。数字平台现在的XML数据库结构，已经不要求记录格式如关系数据库的库表那样整齐划一，可以有相当程度的灵活性；但这也并不意味着什么记录都可以装入一个数据库。如果数据库中的记录格式无法统一，那就无法设计出检索点抽取代码，无法设计出浏览代码，...。这样的数据库只能成为一个垃圾堆，而不是“数据库”了 --- 想要检索的东西检索不出来、数据无法有效利用。
(如果谁不屑于我的这个说法，请设计一个万能的日志库记录结构给我看看。)
为什么一个具有完整功能的书目库需要有配套实体库、期刊库、订购库、评注库等等构成? 这就是数据结构复杂性的一个典型例子。(dt1000曾经实践过把各种业务数据都放在MARC中，但最后证明效率上不是最优，在数据结构设计上也是一个冒险而失败的例子)
在上个世纪90年代，图书馆自动化在国内刚刚兴起的时候，也出现过十几二十年的思想迷乱过程，很多人出于非常原始的想法，以为关系数据库的结构一定能描述好来自西方的MARC数据结构。实际上MARC数据结构完全是为了描述图书馆书目信息而产生的，并没有考虑到所谓数据库乃至关系数据库的方便性。从历史的发展过程来看，恰恰是所谓的数据库技术在不断发展变化以便解决服务于关键业务的本质需要的问题，而不是反过来让业务去符合所谓的数据库技术。
现今，半结构化或者无结构化的数据库都是很多的，世界上并不是只有关系数据库这一种。关系数据库经过努力，可以变革地满足半结构化的需求。但不应该是反之。
另外一个是认为日志库是无能的，什么也解决不了。持有这个想法的朋友，恐怕多是因为在技术上知道的事情太多而有消极遁世的倾向。从统计的角度，确实可以设计出一些具体的数据库结构，满足具体的统计需求，或者一边运作一边改进。虽然远远不是完美主义所期望的那样美好，但确实可以解决很多实际的问题。
所以，请注意避免走两个极端。过程必然是曲折的，会有不少反复。在没有达到一个比较理想的程度以前，我也看不清那个局面到底是一个什么样的局面。