又一年即将过去，戏考除了剧本之外，第二大的业务——梨园百年琐记，也一晃做了八年了。
当然，前三年基本上就是一个 HTML 的表格，此后的五年，数据库的应用加上广大网友积极参与条目的编辑，使得现在的规模已与以前的那个不可同日而语。
因为历史的原因和文化本身的特色，琐记里面的日期从来都是以公历和农历两种历法记录的。以前，这些农历日期都是随着每一个事件条目或者生卒项目一起加入的，随录随加，这就意味着如果有三个事件发生在历史上的同一天，那么公历和农历的对应日期在数据库里会出现三遍。这样所产生的问题是，有时候由于输入或查询的错误，同一个公历日期可能会误出现不同的农历日期。这个问题后来得到了解决，即同一公历日期肯定只对应一个农历日期，但是这个对应的农历日期可能本身就有错，比如把“正月十一”误打成“正月十二”。
而且上面的做法也挺费时的，每次整理事件条目的时候，都要现查一下对应的农历日期。顺便说一下，Google 有一个很好的查询，很方便，比如只要在搜索框里输入“nl 2010-12-31”进行搜索，它就会告诉你农历的对应日期是什么。不过只适用于1900年以后的日期，之前的需要再用单独的万年历程序。
前一阵想起来应该在数据库里做一个大表，把每一个公历的日期都找到相应的农历日期，这样在显示页面的时候直接一查询就好了。包括首页上显示的今日日期，其中的农历日期之前是通过一个函数现算出来的，而这个函数理论上在二零三几年之后就不可用了。人无远虑，必有近忧，这也是要解决的，而最好的解决方法就是上面所说的大表，一劳永逸，而且快。怎么获得农历和公历的对应日期呢？微软的 .NET 有相应的类和函数，用它终于生成了对应表，并且导入到了数据库——花了很长时间导入呢。现在看看，一张大大的表，十八万五千多行的数据，覆盖了自1600年1月1日至2100年12月31日的数据。五百年！
当然，1600年估计早了点儿，万历二十八年，还没戏曲曲艺什么事儿呢。宜早不宜迟，这样肯定够了。而2100年呢？希望那会儿还有值得记的戏曲曲艺事件。2100年之后呢？显然，梨园百年琐记到那会儿就不是我辈能顾及的事儿了。值得操这份儿心么？不知道。也许，最终这个工程会完全开放，由大家自由操作，那么也就不用担心上面那张大表没人去扩展了。操心也没用，现在的数据已经够这辈子弄的了；身后的事，暂不去计较。想得太多太远，就真是“人生不满百，常怀千岁忧”了。若真往远了想，地球有一天都不保，再大的表也没用，我们任何一个项目也是没有用的了——扯远了。
手头上的数据、工程、收藏，在身后会是怎么样的结果？您是否想过？不论如何，休管他今后怎样，我们只要积极向上，把眼前的事情踏踏实实地做好，再稍微考虑一下今后若干年、或者几十年，也就好了。
谨以此与所有努力做着有意义而又征途漫漫、不同道路而有着同样精神的同志们共勉，另：又一岁的新年快乐！