今天校准数据库的时候，发现了一个执行结果不同的现象。经过定位，发现问题出在下面这段代码上。这段代码的执行结果被一个v_request_num的变量所左右。 v_request_num 越小，最后的结果就越少， v_request_num 越大，最后的结果就越多。如果说单次执行的话，这个是废话。但多次执行，直到将表中数据计算完毕后的结果也是这样，着实费解。

先设计好数据结构，然后在数据库里把表建立起来。这样即使前端部分还在写，我一样可以通过直接操作SQL来记录需要记录的东西，可以给前端部分的开发更多的时间。

一条记录的字段应当大致有这样几个：

ID     作为每笔收支的真正的标识符

DATE  日期

TIME   时间

BALANCE  数额

TYPE  币种

IO   收或支，标记一个方向

FT   From/To，记录从哪里来或者到哪里去

USAGE  用途，缘由

日期和时间那里是分开还是合并呢？各有优劣。暂时先决定分开吧，以后看情况。

以上是一条记录应当有的结构。如果建表的话，还需要加入两个字段，一个是表主键，一个是记录的时间。加入表主键而不使用记录的那个ID是因为我想让记录的ID保持紧凑中间不要跳号。表主键就无所谓了。不过这点也许还需要再考虑。 加入记录时间则是因为发生时间和记录时间肯定会不一致的。都在当天也就罢了，要是隔天记录的话，只有一个时间会让统计失去意义的。

最后应当大致如此：

CREATE TABLE fundjour (

  ID  int ,  --- primary Key

  RID int,   -- record id

  DATE  date ,

  TIME  date,

  BALANCE number,

  TYPE varchar,

  IO  int,

 FT  varchar,

 USAGE varchar,

RECORD_TIME date default sysdate  -- 记录时间

)

准备写个记账用的东西，不然不利于培养理财意识。已经半只脚在金融界的了，总得专业点吧。

带图形界面的编程是我的弱项，短时间内根本没法解决，索性回避吧。直接写个命令行操作的，用起来也能更省事更随心所欲一些。

这个东西的要求首先得要足够简洁和方便。每次打字一定要足够少。不然我直接往数据库里写SQL，功能还能更强大更灵活一些。然后得足够地灵活，不要太死板地限制我的输入。虽然多数时候我要求打字少，但也应当支持我话痨的时候。这个东西的功能暂时不需要太多，太多我也想不出来，只要基本的吧。大致应该有以下几个：

1. 资金来往记录的增删查改。

2. 各种分类统计功能。

技术选型还没想好。是把账目都写在文本里面还是弄到数据库里面去也没想好。这个一边做一边考虑吧。先描绘下想要的效果：

1.名字初定为fundjour，命令行输入fdj可调出。

2.调出来的当以 fdj > 打头，其后可输入具体指令操作。

2.1. 操作的指令不要写死，应当有一张列表，可随时修改。

2.2. "fdj > got 3000RMB: expense of Sep."  类似这样的一条表示入账了3000块。冒号后面为原因。这个冒号后面为因由就定死吧，太灵活的话写起来会比较困难。

2.3. 因为操作指令不写死，那么自然应当支持多种同义词。比如说 "fdj > add 3000RMB" 

2.4. 应当支持多点废话，比如说"fdj > I got 3000RMB from company for expense of Septempber"。 这里应当能够正确识别出关键字"got","from","for"。 当然这个要先写到操作指令列表里面去。最前面那个纯废话的"I"，应当能被无视。

2.5. 是否应当支持颠倒的顺序呢？还在犹豫…… 比如说 "From company I got 3000RMB as expense of September"， 这样的应当可以支持吧，但是那个"I" 在这里会比较碍事。 而另一种比如说"Company paid me 3000RMB as expense of September" 这样的，我暂时没办法解析了。算了，颠倒顺序这点就先砍掉吧，等我在自然语言处理上有所成了再回炉。

3. 应当支持直接以命令方式使用，不需要先行进入fdj > 的shell。 命令方式的格式如下：fdj [detail]。比如说" fdj got 3000RMB "。 如果 [detail]为空白，那么默认显示当前月份的账目。

4. 上面写的时候设想的场景都是增加一条记录的，但这个是最简单的。其他的查删改都要难一些。查的话，关键操作符还是一样，由列表指定，具体查询条件应当支持 （1）时间和时间段，（2）缘由的模糊匹配，（3）大致的类别，（4）金额区间，（5）入账出账，（6）分类统计的输出。 具体怎么实现是个问题，就连怎么区分这6类也是个需要考虑的问题。给六类分别指定个不同的指令么？还是带参数？还是统统写在一起让它自己解析？

5.删除功能不需要太灵活。删除的作用本质上是删掉误输入的记录。就给两种格式吧：（1）删除上N条。或者删除上N至M条，或者删除上N,M,X,Y,Z条，或者多个区间。（2）删除记录的某个ID号，某个ID区间，某几个ID号，某几个ID区间。

6.修改功能还没想好。感觉这东西要按命令行的方式来操作的话有点类似在ed中编辑一样，会很憋屈。要不要考虑把那要改的记录搞进vim里，然后改完保存了再提交回去呢？

7. 各种查询统计，也放到指令列表里，对应到具体的统计方式。这货应当是个不断扩展的，光凭现在想必然没法想全了。到时候想到一个加一个进去吧，方便扩展。

从上面看，似乎不用数据库不太现实了。那就弄个数据库吧。前端把字符处理完后，将真正的内容都整进数据库里，然后到数据库里编辑各种统计的业务逻辑，给前端调用，大致就这么个方式吧。只不过这样一来，跨数据库平台就不太好跨了。算了，反正也就我自己用用，不跨也不要紧。SQLite不知道支不支持存储过程，要足够强大的话就用它；要是不行的话就用PostgreSQL。 Oracle虽然好并且我熟悉，但是Gentoo上安装会有麻烦。

前端的输入字符处理会是个难点，具体怎么实现我还得好好想想……

玩过很多RPG游戏，网游中2005年后玩的最多的就是WOW了，这一款也足够经典，可以代表很多类似的作品；而单机的，近年的大作基本都没怎么错过。总的来说，游戏是越做越好了，但是总觉得还有不少可以改进的地方。有些可能会耗费很大的成本，乃至当前技术难以实现；有些则完全是设计上的问题。

这里说的RPG，专指欧美类型的。主要特点是想要营造出一个世界的氛围。我对日式RPG那种所谓剧情流完全不屑一顾。要剧情我何必玩游戏，直接看小说/动漫/电影不就得了，还省时省力。而且还老是烦得要死的回合制，非得回合的话，战斗场景做成战棋类的不更好么……

当前的主流游戏，对于环境的互动还是远远不够。各个游戏中，环境的作用基本上还仅仅只是局限在地形限制上，并且单就这一点，做的也并不完美。地形的限制大体可分三种：禁止移动，减速移动，高处落下。其中高处落下这一点在很多游戏中还并未实现，即便是3D游戏。比如说Dragon Age 和 Wizard 。我称之为“伪3D”。既不能跳，又不会掉下去。断绝了某些地方走捷径的念头，也根除了走路不慎直接摔死的危险，让真实性大打折扣。禁止移动则比较常见了，一堵墙，一块石头之类的，都可以做到类似效果。减速移动算是很能体现“地形”的一点，但是实现这一点的游戏也并不多。当然这里说的是地形，要除开中了陷阱之类的意外状况。WOW里面，能体现减速移动的，好像只有在水里，至于雪地之如冬泉谷，泥泞地之如尘泥沼泽，沙漠之如塔纳利斯，以及各种常见的上下坡，对于移动速度都没有任何影响。其他游戏中，完全不能下水的就有一大把，能下水的那些还好基本上都有实现移动速度上的变化，然而其他的地形却一样没能看到什么影响。既然水中能实现，那么这个完全不是个技术问题，而是个设计问题。倘若能实现这一点，那将更有真实感和代入感，玩家在战斗时也会更注意选择有利地形之类的东西。

说到有利地形，不得不吐槽下WOW中脑残的怪物寻路设定。站在山上打山下，怪物居然完全无视地形可以直接穿过山岩来到你面前的。偶尔找到一个通过发挥自己的优势，比如远程之于近身，站在某个怪物无法攻击到的位置，却会被判为bug，着实让人扫兴。我觉得一个好的RPG游戏，应当鼓励玩家通过利用周遭环境而获得尽可能大的优势，因为现实中人们也是这么做的！

环境不仅包括地形，还有些别的什么，比如说天气。非常多的游戏还没有天气系统，这些落伍于时代的就不提了。但是拥有天气系统的游戏，也大多只是将其当作一种装饰品，而没有什么实际作用。下雨了，刮风了，下雪了，沙尘暴了……不过是自然景观罢了，对穿行于之中的人物没有任何影响。这未免太假了点。我期望能有这样一个游戏，各种天气状况都会产生实际的作用，下雪了，能让人物受到寒冷的影响；刮大风了，能影响相应的行动；下雨了，能把人打湿…… 可惜到目前为止，还从来没有玩到过。要实现这些，技术上完全没有难度，只是增加几个人物属性维度的问题，当然，也会增加整体复杂性倒是真的。

环境中还有各种各样的物品。如何实现与物品的互动算是个大难题。现今的不同游戏有不同的实现方式，直接造成了自由度上的不同。不过受限于技术难度，完美的物品互动没有办法实现。即便自由度如 上古卷轴 这样可以除了主线人物外见谁砍谁的游戏，也没法操作人物用斧子劈了一扇随处可见的门。WOW中，与物品的互动主要通过Loot这一动作来引导实现。开尸体，开箱子，开…… 而其他一些在这点上更主流一些的游戏，会选择 “拾取” 这样一个动作，比如打死怪，地上掉出东西然后捡起来，比如箱子上有个碗，见到后捡起来。也有些是杂糅的，开尸体和开箱子用Loot，捡东西则用拾取，比如上古卷轴。然而无论如何，能互动的物品终究是有限的，划定在一定范围之内的。没打算让你动的东西，是绝对没法动的。这个是RPG游戏中让人沮丧的失真感的主要来源。设想一下，倘若所有的物体，乃至高山乃至地面，都成为可以互动的objects，会是多么让人振奋的事情啊。可惜似乎技术难度太大了点。现今的计算能力也许不足以实现呢。而且还有一个很致命的问题：同一件物品，在现实中可以有很多种不同的使用方式，比如一根棒子，可以当武器进行攻击和防守，可以当延长物去够那些够不着的东西，可以当烤肉架…… 而这个在游戏中会很难实现。特别是要将这世界的所有东西都这么来一下的话，那会是个噩梦。