现在做的是一个OA系统,即办公自公化系统。在这个系统中,有一个个人文件柜和共享文件柜的功能模块。这两个模块的设计思想是这样的:个人文件柜仿网盘的样式,可以参考的有网易网盘和QQ网盘。在网易网盘中,同名问题的处理是,文件夹提示重名,而文件则是遇同名则自动再文件名后,后缀前补(0);QQ硬盘也类似,都是这样一套的防止同名覆盖的方法。
        就个人文件柜,防止同名覆盖。  我设想的方法有两种:第一种就是设计数据库时,文件夹的数据库除了文件夹的路径,文件夹的显示名以外,还有一个字段为服务器硬盘上实际的文件名。在list和其他页面显示时显示的是显示名。文件也是这样的设计方式,即名字分显示名和存储名两种。比如在下载页面,我做的下载页面是用文件名做为标识,从服务器进行下载的,这个时候就是在下载页面上,用的是显示名,这是个链接,点击触发一个action,这个时候传给这个action的名字则是存储名。存储名的生成方式可以有很多,比如在文件名的前面加当前时间,可以精确到天,也可以精确到秒;还可以在文件名前加由数字和字母组成的随机字符串,随机字符串在我的一篇博文里有生成方式。这是一种防止同名覆盖的有效方法。需要注意的是用随机字符串最好size长一些。如果足够长(我觉得6位以上就很够了),再加上同名的概率本来不是十分大,这样的话,同名的机率可以聊到无限接近零。
         还有一种就是同名判断。一般的OA系统几乎所有功能都跟工作流,用户表和角色表发生关系,文件柜虽然没有工作流,但是和用户表(文件柜的所有者)和角色表(文件柜的共享)发生着关系。如果我们进行同名判断,首先获得私人文件柜所有者的ID,因为每个用户都有一个属于自己的D:\privateCabinet\userId的文件夹,获得这个文件夹的ID;然后在文件表中进行条件查询,将所有folderId(外码)为上述文件夹Id的文件查询出来,并且存到list中。然后用一个for循环,循环地将上传文件的文件名与上述各文件记录的文件名进行比较,进行一个模糊的比较,如果发现有两个模糊匹配,我们就将第三个文件命名为文件名(3).后缀。这样的话,数据库就不用多一个字段,但是如果有好多个文件,系统的效率就会有所降低。 
        综合一下,第二种方法可以将同名覆盖的概率降到0,但是在文件记录比较多时,将会牺牲系统的效率;第一种方法可以将同名覆盖的概率降到接近于0,如果随机字符串的长度大到和uuid的长度一样,或者附加的时间精确到毫秒,同名覆盖的概率也可以将到无限接近于0,且这种方法没有牺牲效率的问题。