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