以下是引用 阿甲 于 2013/12/28 9:08:56 发表的文字:
以下是引用 xietao 于 2013/12/27 16:48:15 发表的文字:
在“日志统计窗”，按“方案管理”按钮，进入到“方案管理”对话框。在列表中空白位置点一下右鼠标键，在随后出现的上下文菜单中用“从 dp2003.com 安装方案”。然后会出现一个对话框，在里面打勾选定“借阅排行[分馆]”，点“确定”按钮即可。
非常感谢！已经试用成功了，新的统计方案相当全面，特别是解决了一定期间内没有被借阅的图书统计问题。不过总体感觉，需要等待的时间太长，输出的结果很多，保存不太方便。另外，特别需要的统计结果仍然未能出现，回头我再详细说说那个问题。先说说几个比较直观的问题。
【关于结果的输出】
目前常用的输出方法是逐个表拷贝（因为其实每次不需要那么多项统计），拷贝到Word上比较方便，然后再从Word拷贝到Excel上；但如果表格太多，拷贝起来确实颇为费事。
当然，还有一种办法是通过打印结果转换成PDF格式，不过一来有一定难度，二来仍旧是Excel处理表格最方便。是否有办法选择全部或其中的部分表格，直接另存为Excel表格呢？
如能直接输出Excel表格还有一大好处，就是在全部数据（不仅仅是前100名）输出后可以自由排序，统计人可以自己选择截取所需的排行了。
【关于数据的合并问题】
假设A分馆，有a/b/c/d四个馆藏点，应该是需要A/a A/b A/c A/d四个馆藏点的数据，也需要A分馆总体的数据。当然通过原来的 借阅排行 方案可以实现，但也可以考虑在这个方案中同样输出合并的数据。
【关于统计时间问题】
目前统计的时间很长，需要一边统计一边去做别的事情，回头再来看结果。
观察统计的过程，比如统计一周的和统计一天的结果，发现基本过程大致都是：读取日志；读取读者信息；读取摘要信息；输出……实际上统计一周或一月或一学期的结果，与统计一天的结果，差别主要也是在读取日志的时间上。
缩减时间的可能性：相对固定的信息（比如读者、图书信息）可否预读在什么地方，一定周期预存的记录，当然统计人也可以另选一个最新记录的方法，自愿选择花较长的时间。
还有一种可能性，就是过滤。一种是馆藏点的限定，或者类似的限定；一种是读者类型或读者单位的限定；还有就是统计项目的限定，比如统计人只想查询在一段时间内完全没有被借阅的书，目前可以通过0设置，不输出这项统计。好奇的小问题：是否不输出也不会节省时间？只是不输出表格而已？
尝试以超级管理员的身份统计一周的日志，借阅排行（分馆）产生了97个表。假如能够有些选择或筛选，是否会节省一些时间？而且逐个查看表格确实也相当费力：）
目前这个“借阅排行[分馆]”的统计方案，我主要是给公司同事一个样例，另外最近一段时间可以应对紧急的需求，对这个统计方案可以一直改进。后面我们已经计划编写一个独立的统计系统，就像 dp2circulation 一样成为一个独立的前端程序。
这个统计系统，能够自动调度任务，在每天的某个时刻，统计归纳前一天的报表；在每个月的第一天统计归纳前一个月的报表；在每年的第一天统计归纳前一年的报表；...。由于这种数据挖掘所需要的时间较长，例如要统计一年的数据，所以都是批处理的形式，产生的报表越多越好，毕竟执行一次任务时间较长，而加上去的具体报表多几个并不太影响时间长度。从功能设计上来说，应该是尽量满足“所有”能够预先想到的报表类型，一个也不遗漏。这样，我们可以预计，这个前端模块可以满足日常工作中对报表的绝大部分需求。
这个统计系统，会自动把各种报表，用分馆作为存储目录单位，输出到各种目录中，然后 dp2OPAC 可以提供一个观看这些报表的简单页面，这样图书馆的领导和学校领导就可以随时观看累积起来的报表了。报表的内部存储形式可能是 XML，HTML页面看到的是样式转换后的 HTML，另外还可以下载 Excel 文件的格式。由于 Excel 文件允许多张报表同时存在于一个文件中，所以可以尽可能把报表都存储在单个文件中，例如每个分馆每天一个文件，每月另外有一个文件，每年另外有一个文件。等于打开了这个文件，各种统计报表就一网打尽了，非常方便。
然后，目前的这个统计窗，就逐渐成为少数系统管理员手边的临时工具，需要一种以前没有的报表，用它临时设计一下。如果某种新的报表被发现很有价值，不如推广给所有分馆，那么就可以作为标配加入到上述的报表前端中。
~~~
那么回到现在，这个统计模块可以尽量完善。从技术和方法层面，可以作为对后面那个统计前端的预演。但如果没有清晰的方向，没有归纳，那么显然还是不能满足用户需求的，可能会出现，长期不停提意见，但发现总是解决不了问题、差那么一口气的尴尬局面。
其中速度就是一个很有意思的因素。前天我为了验证这个统计模块，跑了这个方案两次。统计时间范围是 2013 全年。第一次因为要下载日志信息到本地缓存，所以花的时间比较长，大概是两个多小时。第二次统计的时候，由于本地有缓存，那么用于遍历日志数据的时间只有几分钟，花在构造统计报表上面的时间有 40 分钟左右。这 40 分钟，也可以仔细分析。由于我特别关注产生从来没有被借阅的表格，几个馆藏点的藏书都是几千上万册，借阅的部分一般是最多不到一半，剩下的要放入表格中的，由于每行都要加入书目摘要，所以这个 40 分钟的速度应该还算是不错了。打个比方，如果仅仅是检索出这些书目记录，要装入书目查询窗，差不多也要废这个量级的时间。如果不产生这样的流水账报表，相信时间会很快的，几分钟应该够了。
每年要进行一次的统计，耗费这个时间，应该是没有问题的。如果作为例行任务安排，程序自动执行了，那用户就感觉不到时间有什么问题。好比现在 dp2OPAC 的浏览格式创建任务，作为后台任务是可以接受的，但作为每次浏览的时候实时执行，这个用户就忍受不了了。还是拿在饭馆吃饭打个比方，炖牛肉之类的菜需要计划性，头天炖好，不像炒菜那样当时可以现炒。顾客到饭馆点菜点炖牛肉的时候，实际上是加热的时间，不是从头到尾炖好所耗费的时间。
但目前在调整和验证测试的阶段，本来每年一次的统计，也需要反复跑，调整，验证，当然每次时间是越短越好。
~~~
下面逐个回答问题：
> 另外，特别需要的统计结果仍然未能出现
这个从程序员的角度，可能站位不是那么高，不知道用户感兴趣什么，只要提出来应该就是可以实现的。
> 需要等待的时间太长
上面已经解释了，总结一下，就是第二次执行的时候，本地有缓存，时间会大大加快；另外以后安排成自动执行的任务，时间也就不是问题了。
> 目前常用的输出方法是逐个表拷贝（因为其实每次不需要那么多项统计），拷贝到Word上比较方便，然后再从Word拷贝到Excel上；但如果表格太多，拷贝起来确实颇为费事。
可以增加一个另存到 HTML 文件的功能，把所有表格都保存为单独的 HTML 文件。这个统计方案，HTML 是原生的格式。
如果要保存到 word 格式，开发有一定的成本，格式设定等比较费事，所以程序员会希望把需求稳定好了以后，作为对最终用户的一个正式开发任务提出来。这里有个身份的问题，如果是阿甲使用，鉴于是有经验的系统管理员，可能很多功能就因陋就简了，其实我们对自己的需求也是这么理解的。如果转换一个角度，认为这是给最终的用户开发的非常正式的功能，那 word 和 excel 格式就可以提到台面上来。思考方式也可以是这样：将来馆长和校长直接在电脑上打开这些页面或者文件。而上面说了，让领导下载安装一个 dp2circulation，弄清楚账户名密码，然后找到几级菜单，弄清楚这么复杂的操作过程，这是扭曲的。实话说这些模块本来就是设计给系统管理员的，不是给领导亲自操作的。
如果考虑过渡期，可以假设，系统管理员操作好了，把这些文件归纳后存储到适当的目录，让领导方便打开。也就是说不让领导接触这个复杂的启动操作过程。看看最近用这个角度进行改进是否可以？所谓完美的功能，等后面那个统计模块出来统一解决。
> 当然，还有一种办法是通过打印结果转换成PDF格式，不过一来有一定难度，二来仍旧是Excel处理表格最方便。是否有办法选择全部或其中的部分表格，直接另存为Excel表格呢？如能直接输出Excel表格还有一大好处，就是在全部数据（不仅仅是前100名）输出后可以自由排序，统计人可以自己选择截取所需的排行了。
上面已经提到了，可以把 Excel 和 HTML 都作为主格式。单一用 Excel 不行，因为网页查看不了，领导时间紧想看几个数字，未必有耐心打开 Excel 文件。但 Excel 确实功能很强大，打印前可以调整，有能力的系统管理员还可以作为素材创建其他表格。有了 Excel 格式，word 格式似乎就可以不要了，因为 Office 里面这几个格式可以方便互相粘贴，Excel 的存储表格信息更专业一些。
不过这是最完美的解决方式了。最近一段时间，是否还是继续用 HTML 格式？还是要同时输出为 Excel ? 也不算太难，权且当作一种演练吧。
> 假设A分馆，有a/b/c/d四个馆藏点，应该是需要A/a A/b A/c A/d四个馆藏点的数据，也需要A分馆总体的数据。当然通过原来的 借阅排行 方案可以实现，但也可以考虑在这个方案中同样输出合并的数据。
从统计方案的角度，可以在统计的时候就给出分馆归纳的数据，例如一个分馆四个阅览室，应该是产生五张表格，有一张是分馆整体汇总表。
但从 Excel 表格的角度，实际上是可以产生好表格以后再汇总也可以的。基础表可以创建出任何延伸的表格。今后在编制统计方案的时候，什么是原生的表格，什么是表格加工后的表格，可以定出一个规则。另外，从时间角度，一个月的每天的表格，可以汇总出月份的表格，并不需要重新跑一次统计。这里的思路很多，需要好好好梳理一下。
> 缩减时间的可能性：相对固定的信息（比如读者、图书信息）可否预读在什么地方，一定周期预存的记录，当然统计人也可以另选一个最新记录的方法，自愿选择花较长的时间。
上面提到，以后成为固定的任务就好了。
> 还有一种可能性，就是过滤。一种是馆藏点的限定，或者类似的限定；一种是读者类型或读者单位的限定；还有就是统计项目的限定，比如统计人只想查询在一段时间内完全没有被借阅的书，目前可以通过0设置，不输出这项统计。好奇的小问题：是否不输出也不会节省时间？只是不输出表格而已？
是的，跑一趟统计，多产生几个表格，所费的时间并不多。时间主要花在跑一趟上面，好像去外地出差，到了目的地发现忘带东西了，回来拿一次就太费时间了，最好是一趟什么都带齐。这是数据挖掘的特点，此类任务都不是瞬间可以完成的。
> 尝试以超级管理员的身份统计一周的日志，借阅排行（分馆）产生了97个表。假如能够有些选择或筛选，是否会节省一些时间？而且逐个查看表格确实也相当费力：）
现在这个统计方案输出 HTML 表格，当然是一堆都堆在一起了。从简单的角度，也想不出来有什么办法组织这些表格，例如，创建一个 index.html 网页，列出这些表格的名字，点了再进去看？这种方法，已经是上面说的最终产品的想法了，不是试验时候舍得采用的。
(其实从我编程的角度，已经考虑到把同一个分馆的同类表格尽量聚集在一起了。因为开发中用到了 hashtable，本来名称出来都是乱的顺序，我特意加了一个排序的语句了)
如果是输出 Excel 的表格，因为一个 Excel 文件可以聚集好多表格，所以可以每个分馆产生一个 Excel 结果文件。但到了打开每个 Excel 文件，里面的多个表格排列起来岂不是还是线性的，也需要一个一个顺次去看，没有什么层次结构。
~~~
后面我再改进一个版本，然后我们再看看哪些满足了，哪些还需要继续改进。在这个时间里，我们等待最终的统计模块出来。