dp2图书馆集成系统，在dp2circulation前端的采购流程中，实现了单角色库和多角色库两种工作模式。
单角色库就是直接在中央库的记录中进行订购。而多角色库是在中央库之外设立了一种订购角色的书目库，订购操作的时候，会把复本订购的书目记录从中央库复制到订购书目库中，当验收的时候，又会把订购书目库中的书目记录合并回中央库中。
本来单角色库的模式就可以满足任何规模的图书馆的业务需求，但一些用户单位因为有dt1000的运作经验，可能想当然地以为多库是更“高级”的模式，所以我们也开发了多角色库的工作模式。不过，需要强调的是，实际上多角色库的模式增加了不少工作量，概念也比较复杂一些。所以，除非是满足某种心理需求，多角色库模式是没有必要的。
多角色库模式下，为了解决书目记录复制出来、然后合并回去的定位问题，系统在书目记录的998字段增设了一个$t子字段，用来记录“目标记录的路径”。书目记录从中央库复制到工作库之后，工作库的那条记录里面就被自动添加了一个998$t子字段，内容是中央库记录的路径。这样，当流程进行到后期，工作库的这条记录需要合并回中央库的时候，998$t中记载的路径就能发挥作用。
998$t这么一个小小的子字段，里面蕴含了很多东西。在多角色库模式下，工作人员决定把一条记录从中央库复制到工作库以便完成业务操作，必然是经历了一系列的辨认识别之后才操作的。虽然作为一种工具，软件本身并未参与这种复杂的辨认识别过程，但一旦工作人员决定下来，那么998$t就负责去记载两条记录之间的“正本-副本”关系。
记载这个“关系”非常重要。如果不记载这个关系，日后流程需要把工作库的记录合并回中央库的时候，就需要借助普通的查重操作，到时候工作人员又要费心费力去辨认记录之间的源流关系，这是一种浪费。因为在当初决定复制的时候，工作人员已经进行过一次辨认识别的脑力劳动，软件大可以记载下这第一次劳动的成果，免去日后合并回去时的又一次脑力劳动。
从事图书馆软件设计这么多年，我觉得一个比较难的问题就是查重问题，即辨别书目记录之间的源流关系的问题。很多朋友天真地以为软件能自动完成处理，但若干年的经验告诉我，软件至多是个不太合格的工具而已，在关键环节还是需要人的脑力介入。如果软件越俎代庖，形成结果可能是一片垃圾数据，工作人员不知道问题很严重了，或者明知道问题很严重但是故意不去想它。我认为，软件还是应该固守其擅长的“工具”地位，仅仅是在人工判断以后进行忠实地记录和还原，把这种表面上看起来并不算很高级的工作做好，总比连这个都做不好还要去做更难的事情来的更合适。
998$t的作用当然不仅仅是为订购流程服务，它实际上更多是为了编目流程服务。