，然后点击“添加到主屏幕” 笔趣阁 www.biquge3.cc，公文写作知识无错无删减全文免费阅读！
3。3基于内容的全文检索查询
指定通过公文标题、发文机关等元素内容，查找满足条件的公文，是基本的数据库查询操作，比较容易实现。但是在公文的查找中存在一类需求，即用户只记得公文的大致内容，如公文内容中包含的几个关键词，但是关于公文更详细的内容如发文时间、发文机关名称等并不清除。在这种情况下需要对公文进行基于内容的全文检索查询。
该功能的实现流程如图2所示。对数据库中的每条记录，均先将对应的word文档保存到本地，然后用delphi的tworddocument类打开。tworddocument类的content属性为range对象，调用其find。execute方法可以在该范围内进行文本查找，功能与word应用程序中调用“编辑-查找”功能菜单一样，不仅可以进行基本的查找，还可以通过参数控制在查找过程中是否区别大小写、是否使用通配符等。如果匹配成功，则该方法返回true，系统为该条记录做好标记，作为查询结果中的一条进行显示。当数据库中所有的记录都处理完后，查询处理结束，所有被标记的记录均为满足条件的结果，即内容中包含指定关键词的公文。
3。4文档版本控制
“临时公文管理”模块主要是将正在撰写尚未正式定稿的公文存放到数据库中进行备份，同时支持同一稿件在撰写修改过程中产生的多个不同版本维护功能。文档修改前后的比较、版本控制是这一模块的主要技术点。
版本控制主要是通过获取文件最近修改时间来实现的。具体来说包括以下步骤:1）系统启动时，通过oracle中的sysdate函数取得数据库服务器的当前时间，并将客户端时间与服务器时间进行自动同步；2）临时公文上传到服务器进行备份时，获得文件的最近修改时间并保存在数据库中的updatetime字段中；3）检查本地文件与数据库备份文件是否一致时，再次获得本地文件的最近修改时间，通过与数据库中保存的时间进行比
较完成。
获取文件最近修改时间功能实现，主要是通过windows的api函数findfirstfile获得文件属性数据，该数据的ftlastwritetime属性即为文件的最后修改时间。值得注意的是，该属性获得的是用32位表示的文件时间戳，为操作系统使用。要想转换为用户能看懂的本地系统时间，需要通过filetimetolocalfiletime、filetimetosystemtime以及systemtimetodatetime函数进行转换。
4测试验证
为了验证依据上述分析设计的有效性，对已实现的公文管理系统进行了测试验证。
4。1实验设置
试验在2台pc机组成的局域网内进行。数据库服务器的基本配置为piv2。0gcpu，1g内存，120g硬盘，其上安装了oracle9i；客户端pc机配置为piii1gcpu，512m内存，80g硬盘，安装了oracle客户端和officexx软件。
实验数据集为某单位xx-xx。6产生的500个实际公文文件，大小从50k到500k不等，平均大小约为200k。在其上进行了存储开销比较、查询性能、自动归档性能以及全文检索性能的实验。
4。2实验结果
采用三种存储方案对公文进行存储，考查随公文数增加不同方案存储开销之间的差异，如图3所示。其中方案一为所有元素均分离存储；方案二为仅存储完整的公文文件；方案三为本文采取的折中方案。
可以看出，方案一所需空间最小，方案二其次，方案三所需空间最大。这是因为，方案一仅保存了必须的文本内容，而且不同元素之间相互无重叠冗余；而方案二存储的完整文件除了包含字符格式、字体等信息外，还包含doc文件必须的文件格式头等内容，因此所需空间较大。方案三在方案二的基础上还冗余存储了一些元素内容，因此所需空间最大。但总体看来，方案三与方案二相比，额外所需的存储空间并不是很大，约占文件大小的0。51%左右。
三种存储方案下普通查询的效率和原文档恢复所需时间分
比较别如图4、图5所示。可以看出，方案三普通查询的效率与方案一几乎没有差别，受益于oracle数据库管理系统的查询性能，在实验数据规模上返回结果的时间为毫秒级；而方案二由于需要还原文件后再进行全文检索，所需时间较长，尤其随着数据库中记录数增加所需时间也线性增加，当数据规模较大时难以满足用户需求。而在文档恢复方面，方案一需要将所有内容进行重组，并按照公文承办规定设置相关元素的格式等，所需时间为秒级，而且恢复效果较差；而方案二和方案三直接从数据库中读取完整文档并恢复，所需时间仅为毫秒级。
在采用第三种存储方案实现的系统中，随归档文档数的增加，系统自动归档所需时间情况如图6所示。可以看出，系统具有较高的自动分析和批量归档功能，平均每个文档所需的分析归档时间不足1秒。因此能够较好满足归档需求。
系统全文检索效率如图7所示。可以看出，全文检索所需时间与随公文数目增加呈线性增加，平均处理每个公文所需的时间约为200毫秒。因此，当公文数目较多时，建议先通过普通查询缩小全文检索范围，可以有效降低全文检索的响应时间。
5结束语
基于delphi和oracle数据库，结合msword的vba相关功能，设计并实现了一个电子公文管理系统，探讨了其总体结构及设计实现相关的关键内容，并通过大量实验验证了上述工作的有效性。该系统目前已经投入使用，运行稳定，性能良好，也在一定程度上验证了本文工作的可行性。
3。3基于内容的全文检索查询
指定通过公文标题、发文机关等元素内容，查找满足条件的公文，是基本的数据库查询操作，比较容易实现。但是在公文的查找中存在一类需求，即用户只记得公文的大致内容，如公文内容中包含的几个关键词，但是关于公文更详细的内容如发文时间、发文机关名称等并不清除。在这种情况下需要对公文进行基于内容的全文检索查询。
该功能的实现流程如图2所示。对数据库中的每条记录，均先将对应的word文档保存到本地，然后用delphi的tworddocument类打开。tworddocument类的content属性为range对象，调用其find。execute方法可以在该范围内进行文本查找，功能与word应用程序中调用“编辑-查找”功能菜单一样，不仅可以进行基本的查找，还可以通过参数控制在查找过程中是否区别大小写、是否使用通配符等。如果匹配成功，则该方法返回true，系统为该条记录做好标记，作为查询结果中的一条进行显示。当数据库中所有的记录都处理完后，查询处理结束，所有被标记的记录均为满足条件的结果，即内容中包含指定关键词的公文。
3。4文档版本控制
“临时公文管理”模块主要是将正在撰写尚未正式定稿的公文存放到数据库中进行备份，同时支持同一稿件在撰写修改过程中产生的多个不同版本维护功能。文档修改前后的比较、版本控制是这一模块的主要技术点。
版本控制主要是通过获取文件最近修改时间来实现的。具体来说包括以下步骤:1）系统启动时，通过oracle中的sysdate函数取得数据库服务器的当前时间，并将客户端时间与服务器时间进行自动同步；2）临时公文上传到服务器进行备份时，获得文件的最近修改时间并保存在数据库中的updatetime字段中；3）检查本地文件与数据库备份文件是否一致时，再次获得本地文件的最近修改时间，通过与数据库中保存的时间进行比
较完成。
获取文件最近修改时间功能实现，主要是通过windows的api函数findfirstfile获得文件属性数据，该数据的ftlastwritetime属性即为文件的最后修改时间。值得注意的是，该属性获得的是用32位表示的文件时间戳，为操作系统使用。要想转换为用户能看懂的本地系统时间，需要通过filetimetolocalfiletime、filetimetosystemtime以及systemtimetodatetime函数进行转换。
4测试验证
为了验证依据上述分析设计的有效性，对已实现的公文管理系统进行了测试验证。
4。1实验设置
试验在2台pc机组成的局域网内进行。数据库服务器的基本配置为piv2。0gcpu，1g内存，120g硬盘，其上安装了oracle9i；客户端pc机配置为piii1gcpu，512m内存，80g硬盘，安装了oracle客户端和officexx软件。
实验数据集为某单位xx-xx。6产生的500个实际公文文件，大小从50k到500k不等，平均大小约为200k。在其上进行了存储开销比较、查询性能、自动归档性能以及全文检索性能的实验。
4。2实验结果
采用三种存储方案对公文进行存储，考查随公文数增加不同方案存储开销之间的差异，如图3所示。其中方案一为所有元素均分离存储；方案二为仅存储完整的公文文件；方案三为本文采取的折中方案。
可以看出，方案一所需空间最小，方案二其次，方案三所需空间最大。这是因为，方案一仅保存了必须的文本内容，而且不同元素之间相互无重叠冗余；而方案二存储的完整文件除了包含字符格式、字体等信息外，还包含doc文件必须的文件格式头等内容，因此所需空间较大。方案三在方案二的基础上还冗余存储了一些元素内容，因此所需空间最大。但总体看来，方案三与方案二相比，额外所需的存储空间并不是很大，约占文件大小的0。51%左右。
三种存储方案下普通查询的效率和原文档恢复所需时间分
比较别如图4、图5所示。可以看出，方案三普通查询的效率与方案一几乎没有差别，受益于oracle数据库管理系统的查询性能，在实验数据规模上返回结果的时间为毫秒级；而方案二由于需要还原文件后再进行全文检索，所需时间较长，尤其随着数据库中记录数增加所需时间也线性增加，当数据规模较大时难以满足用户需求。而在文档恢复方面，方案一需要将所有内容进行重组，并按照公文承办规定设置相关元素的格式等，所需时间为秒级，而且恢复效果较差；而方案二和方案三直接从数据库中读取完整文档并恢复，所需时间仅为毫秒级。
在采用第三种存储方案实现的系统中，随归档文档数的增加，系统自动归档所需时间情况如图6所示。可以看出，系统具有较高的自动分析和批量归档功能，平均每个文档所需的分析归档时间不足1秒。因此能够较好满足归档需求。
系统全文检索效率如图7所示。可以看出，全文检索所需时间与随公文数目增加呈线性增加，平均处理每个公文所需的时间约为200毫秒。因此，当公文数目较多时，建议先通过普通查询缩小全文检索范围，可以有效降低全文检索的响应时间。
5结束语
基于delphi和oracle数据库，结合msword的vba相关功能，设计并实现了一个电子公文管理系统，探讨了其总体结构及设计实现相关的关键内容，并通过大量实验验证了上述工作的有效性。该系统目前已经投入使用，运行稳定，性能良好，也在一定程度上验证了本文工作的可行性。