前一阶段没有顾及blog...反省中...
光盘扫描好办.但是如果扫描一个DVD,文件数目可能会相当大.假设一个DVD有3万个文件,文件名长度10字节,外加目录名.很可能突破1M或者更多.这样多的条目如果用insert来搞是不是很恐怖?而且客户上传需要等待处理时间不也是很长? 3w条数据,上次测试过,结果给忘了,反正本地也需要消耗很多时间.
那么怎么办?
1 减少无用文件数目,将垃圾文件列表整理成一个txt或者lst文件,然后写入数据库的Text字段,但是这样就不方便搜索了... 所以某些用户标记的,单独一条记录,用varchar存储,剩下的近乎垃圾的就用text存储.这样打开某个光盘之后再读取text字段的内容用程序的办法搜索.
优点,节约记录条目数量 提升速度 缺点,不能搜索text的数据(主要还是为了速度)
2 将全部列表=>XML 或者其他的什么数据文件,然后将这个Stream=>Server, Server慢慢处理,这样可以大量减少 用户等待的时间.而且上传之后,至于Server怎么处理,这个就是Server说的算了,也许Server定义的规则就是不允许垃圾数据,所以直接被过滤了也可能.或者Server定期从这些文件里面加载一部分记录.对于服务器间互操作来说.这样可以添加计划任务.跟刚才第一种方案差不多,但是不是放在text里面罢了.
优点,节约用户上传的时间.而且这个基于文件的,容易备份恢复.
缺点,服务器必须建立这样的文件管理程序.
3 我们建立的这套猫猫系统是后台服务的.也就是说,把当前作业提交到服务以后.服务做什么就不需要上层应用程序知道了.因此.可以给服务加一个持久的,频繁的同步作业.就是说.把当前扫描的数据插入到本地数据库.然后利用同步的办法.(降低线程优先级,免得占用过多的CPU) 定时定量的与服务器同步.这样造成的结果可能会同步N9... 本地也要计算给出一个同步列表以及后台的同步进度条.提示用户现在正在同步数据.
优点, 舒适... 用户不必关心应该做什么
缺点,时间长,而且问题也不少,需要考虑的问题多
=========================================
纵上,或许可以结合一下上述三种办法的优点.但是如果这套东西过于健壮了,需要编码设计的时间也会变长,工程更难以控制.... 但是可以满足多种人的需要.比如的三种方式就很适合服务器间互操作. 第二种方式适合在外的人直接上传到服务器(比如dir f:/s>c:\dvd1.lst)基本上用浏览器就够了,第一种适合单条记录添加,比如刚刚得知一个文件的位置,然后手动添加,同样用BS也就能解决
真的要全部支持吗???? 如果设计接口的话... 数据库存储结构应该一样吧...
第一种方法: 需要一个text字段存放内容
第二种方法:需要一个varchar存放上传之后的文件地址,还需要做一个文件管理,数据库缓存,以及文件筛选策略,清理策略
的三种方法:需要做同步策略,
我尝试整合一下:
默认的,如果有客户端或者系统服务,可以用的三种方法,外加前两种的综合
以第二种方法为主,上传之后,存放在文件目录里面.然后筛选结果到方法1.如果用户打开了记录,那么将整个文件的内容填充到 text字段.否则,添加一个计划任务.长时间不用的给清理掉一部分(很危险的步骤)这样三者就基本统一了.
如何算作长时间不用的东西给清理掉?
删除是不行的,因为用户要搜索的东西往往就是长时间不用的
但是对于速度来说这又是矛盾的!所以需要两个表
1 经常使用的列表,而且都是带有备注的,可以被清理的
2 全部的文件表,不能被清理的而且具有text属性的
3 文件目录,里面都是lst文件.理论上不能被清理,除非光盘报废了,被标志为X的或者空占用过于庞大的.
希望有更好的办法解决这个问题.
光盘扫描好办.但是如果扫描一个DVD,文件数目可能会相当大.假设一个DVD有3万个文件,文件名长度10字节,外加目录名.很可能突破1M或者更多.这样多的条目如果用insert来搞是不是很恐怖?而且客户上传需要等待处理时间不也是很长? 3w条数据,上次测试过,结果给忘了,反正本地也需要消耗很多时间.
那么怎么办?
1 减少无用文件数目,将垃圾文件列表整理成一个txt或者lst文件,然后写入数据库的Text字段,但是这样就不方便搜索了... 所以某些用户标记的,单独一条记录,用varchar存储,剩下的近乎垃圾的就用text存储.这样打开某个光盘之后再读取text字段的内容用程序的办法搜索.
优点,节约记录条目数量 提升速度 缺点,不能搜索text的数据(主要还是为了速度)
2 将全部列表=>XML 或者其他的什么数据文件,然后将这个Stream=>Server, Server慢慢处理,这样可以大量减少 用户等待的时间.而且上传之后,至于Server怎么处理,这个就是Server说的算了,也许Server定义的规则就是不允许垃圾数据,所以直接被过滤了也可能.或者Server定期从这些文件里面加载一部分记录.对于服务器间互操作来说.这样可以添加计划任务.跟刚才第一种方案差不多,但是不是放在text里面罢了.
优点,节约用户上传的时间.而且这个基于文件的,容易备份恢复.
缺点,服务器必须建立这样的文件管理程序.
3 我们建立的这套猫猫系统是后台服务的.也就是说,把当前作业提交到服务以后.服务做什么就不需要上层应用程序知道了.因此.可以给服务加一个持久的,频繁的同步作业.就是说.把当前扫描的数据插入到本地数据库.然后利用同步的办法.(降低线程优先级,免得占用过多的CPU) 定时定量的与服务器同步.这样造成的结果可能会同步N9... 本地也要计算给出一个同步列表以及后台的同步进度条.提示用户现在正在同步数据.
优点, 舒适... 用户不必关心应该做什么
缺点,时间长,而且问题也不少,需要考虑的问题多
=========================================
纵上,或许可以结合一下上述三种办法的优点.但是如果这套东西过于健壮了,需要编码设计的时间也会变长,工程更难以控制.... 但是可以满足多种人的需要.比如的三种方式就很适合服务器间互操作. 第二种方式适合在外的人直接上传到服务器(比如dir f:/s>c:\dvd1.lst)基本上用浏览器就够了,第一种适合单条记录添加,比如刚刚得知一个文件的位置,然后手动添加,同样用BS也就能解决
真的要全部支持吗???? 如果设计接口的话... 数据库存储结构应该一样吧...
第一种方法: 需要一个text字段存放内容
第二种方法:需要一个varchar存放上传之后的文件地址,还需要做一个文件管理,数据库缓存,以及文件筛选策略,清理策略
的三种方法:需要做同步策略,
我尝试整合一下:
默认的,如果有客户端或者系统服务,可以用的三种方法,外加前两种的综合
以第二种方法为主,上传之后,存放在文件目录里面.然后筛选结果到方法1.如果用户打开了记录,那么将整个文件的内容填充到 text字段.否则,添加一个计划任务.长时间不用的给清理掉一部分(很危险的步骤)这样三者就基本统一了.
如何算作长时间不用的东西给清理掉?
删除是不行的,因为用户要搜索的东西往往就是长时间不用的
但是对于速度来说这又是矛盾的!所以需要两个表
1 经常使用的列表,而且都是带有备注的,可以被清理的
2 全部的文件表,不能被清理的而且具有text属性的
3 文件目录,里面都是lst文件.理论上不能被清理,除非光盘报废了,被标志为X的或者空占用过于庞大的.
希望有更好的办法解决这个问题.
