人生不满百,常怀千岁忧

又一年即将过去,戏考除了剧本之外,第二大的业务——梨园百年琐记,也一晃做了八年了。

当然,前三年基本上就是一个 HTML 的表格,此后的五年,数据库的应用加上广大网友积极参与条目的编辑,使得现在的规模已与以前的那个不可同日而语。

因为历史的原因和文化本身的特色,琐记里面的日期从来都是以公历和农历两种历法记录的。以前,这些农历日期都是随着每一个事件条目或者生卒项目一起加入的,随录随加,这就意味着如果有三个事件发生在历史上的同一天,那么公历和农历的对应日期在数据库里会出现三遍。这样所产生的问题是,有时候由于输入或查询的错误,同一个公历日期可能会误出现不同的农历日期。这个问题后来得到了解决,即同一公历日期肯定只对应一个农历日期,但是这个对应的农历日期可能本身就有错,比如把“正月十一”误打成“正月十二”。

而且上面的做法也挺费时的,每次整理事件条目的时候,都要现查一下对应的农历日期。顺便说一下,Google 有一个很好的查询,很方便,比如只要在搜索框里输入“nl 2010-12-31”进行搜索,它就会告诉你农历的对应日期是什么。不过只适用于1900年以后的日期,之前的需要再用单独的万年历程序。

前一阵想起来应该在数据库里做一个大表,把每一个公历的日期都找到相应的农历日期,这样在显示页面的时候直接一查询就好了。包括首页上显示的今日日期,其中的农历日期之前是通过一个函数现算出来的,而这个函数理论上在二零三几年之后就不可用了。人无远虑,必有近忧,这也是要解决的,而最好的解决方法就是上面所说的大表,一劳永逸,而且快。怎么获得农历和公历的对应日期呢?微软的 .NET 有相应的类和函数,用它终于生成了对应表,并且导入到了数据库——花了很长时间导入呢。现在看看,一张大大的表,十八万五千多行的数据,覆盖了自1600年1月1日至2100年12月31日的数据。五百年!

当然,1600年估计早了点儿,万历二十八年,还没戏曲曲艺什么事儿呢。宜早不宜迟,这样肯定够了。而2100年呢?希望那会儿还有值得记的戏曲曲艺事件。2100年之后呢?显然,梨园百年琐记到那会儿就不是我辈能顾及的事儿了。值得操这份儿心么?不知道。也许,最终这个工程会完全开放,由大家自由操作,那么也就不用担心上面那张大表没人去扩展了。操心也没用,现在的数据已经够这辈子弄的了;身后的事,暂不去计较。想得太多太远,就真是“人生不满百,常怀千岁忧”了。若真往远了想,地球有一天都不保,再大的表也没用,我们任何一个项目也是没有用的了——扯远了。

手头上的数据、工程、收藏,在身后会是怎么样的结果?您是否想过?不论如何,休管他今后怎样,我们只要积极向上,把眼前的事情踏踏实实地做好,再稍微考虑一下今后若干年、或者几十年,也就好了。

谨以此与所有努力做着有意义而又征途漫漫、不同道路而有着同样精神的同志们共勉,另:又一岁的新年快乐!

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注