建立解谜数据库的最主要目的是，提供迅速快捷的解谜信息的查询。
另外，还可以利用数据库排序、选择的基本操作，来实现自动选择执行任务的功能，
这点我会在下一章里详细说明。
下面就开始搭建全自动解谜系统的基石——解谜数据库。
在Zmud 5.x和6.x版本中，工具栏里有个DB按钮，通过它进入Zmud的数据库模块。
根据上面列出的两个目的，我建立了两个数据库：一个是静态的数据库Record.db，
一个是动态的数据库Quest.db。
Record.db用来保存所有的解谜任务，里面的内容只能通过数据库的数据管理来做修改，
在自动解谜系统工作的时候，它的内容是不会发生变化的；
Quest.db用来记录当前的解谜任务，总共七条记录，
它的内容随着解谜的进行不断更新，
并且通过建立Quest.db的视图按条件选取下一个该执行的任务。
两个数据库的构造如下：
Record.db
这个数据库的记录有6个字段(Field)：
Type(任务类型，该字段为Single Option类型，字段的值为
食物、送物、拜贤、灭妖、武器、盔甲、募捐之一。)
Name (任务名称， 字段类型Text)
Ename(任务英文名称， 字段类型Text)
Extra(任务附加选项， 字段类型Text)
Place(任务地点， 字段类型Text)
Todo (执行该任务的命令， 字段类型Memo)
Type字段将任务的类型加以区分，对应七种不同的任务种类；
Name和Ename字段在不同任务中分别对应食物、武器、盔甲、募捐的物品和送物、
拜贤的人物的中文名及英文名；Extra字段在送物中对应所送物品名称，
在拜贤中对应所询问事宜；Place字段记录任务中人物或物品所在地点；
最后一个Todo字段是最重要的，记录了执行该任务的命令操作。举例如下：
Type Name Ename Extra Place Todo
拜贤 大和尚 he shang 佛学 车迟/金平府/乌鸡 略
在实际操作中，Place字段是可以省略的，但考虑到对新手具有提示作用，把该字段保留了。
建好了Record.db的框架，我们可以把记录向里面添加进去了。
如果用手动一个个填写添加，不但容易出错、遗漏，而且工作量大的惊人。
幸好Zmud的数据库对记录的输入提供了Import的功能，可以直接从文件中读入。
Import可以从两种文件读入记录，一种是普通的txt文件，这种txt文件每行为一个记录，
不同字段用Tab隔开；另一种是csv文件，用逗号(comma)来间隔字段。
实际上，这两种文件的区别只在于间隔 符号的不同，我们无须刻意选择，
因为在Import的时候，可以向Zmud指定说明间隔符号的类型。
为减少工作量，我以源码中的任务列表(/d/kaifeng/npc/quest_*.c)
为基础，把其中无用及重复的任务剔除掉，进行整理补充，将所有记录保存在QuestDB.txt中。
然后将这个txt文件Import到数据库中。在选择完Import文件之后，Zmud将弹出一个对话框，
把各个字段及其相应记录显示在一个预览表格里，如果正确，将自动把文件里的
每个记录添加到Record.db中去。这一步是相当便捷的，
也使我的热情没被添加记录的繁琐给磨灭。:)
建立完成之后，Record.db里总计有大约1800条记录。
Quest.db
我在这个数据库中新建了四个域(Field)，其名称与类型分别如下：
Type (任务的类型， 字段类型Single Option)
Name (任务的名称， 字段类型Text)
Cloud(是否有云， 字段类型Boolean)
NotDo(多久未完成该项任务， 字段类型number)
Type、Name的作用与Record.db中的Type、Name一样；Cloud字段是个布尔量，非零即一，
记录对应此任务的云是否存在；NotDo字段记录此任务有多久未做。
我们知道，食物、送物、拜贤、灭妖、武器、盔甲、募捐七种任
务对应的云彩分别为红、青、绿、黄、蓝、粉、白。输?quot;Quest"命令
查看当前任务的时候，可以知道身上有哪几朵彩云。我们可以利用函
数%pos(para1，para2)来得到Cloud字段的值。例如：
“慢慢地一小团红白两色祥云在你的身边升起。”
我们就得到一个Colorlist=“红白”，%pos(红，@colorlist)可
以返回“红”这个字在字符串“红白”中的位置，如果不存在则返回值为零。
因为Cloud字段为布尔量，如果需要查找的字存在于字符串中，则返回值非零，
赋给Cloud就为一；反之则为零。利用这个方法
我们可以得知哪些任务有相应的云彩存在，哪些没有，为选择任务打 好基础。
建好了这两个数据库，我们可以开始构建上层建筑了。后面，我们继续讨论：
