在10年的大部分时间里,我们依靠各种网络映射驱动器来允许文件共享。一个用于在团队之间共享文件的驱动器号,一个用于整个组织的单独文件共享,三个用于个人用途的驱动器号。我想摆脱这一点并且我试图决定ECM / Sharepoint类型解决方案,还是本土应用程序,是值得的成本和方式去?或者,由于相对简单,我们是否应该继续依赖登录脚本/映射驱动器进行文件共享?是否有人在自己的组织内有任何经验或对此有何看法?
感谢。
答案 0 :(得分:3)
SharePoint非常擅长文档共享。
文档通常遵循批准流程,拥有权限,以群集形式存在......这些东西很适合SharePoints文档库。
然而,有些东西不能很好地适应内部生活...你有一个虚拟硬盘(.vhd)文件,你想与同事分享?尝试将20GB文件放入SharePoint中并不是一个好主意。
SharePoint可以处理大型文件,SQL Server也可以处理它...但是您希望SQL Server带宽被这些大文件所饱和吗?您是否希望备份SQL Server多次保存此类大型文件的副本?
我相信有一些Microsoft合作伙伴能够解除文件blob与SharePoint数据库的关联,因此SharePoint可以保存元数据,文件系统可以保存实际文件,而SharePoint只是成为管理访问权限的网关,权限,并为整个组织的文件提供集中的界面。这将为您提供两全其美的优势。
现在,我认为SharePoint是文档的理想选择,我在Windows文件共享上保留大文件(不是以文档为中心)。
答案 1 :(得分:0)
定义,使用工具。
这里的主要好处是版本控制。能够轻松跳转到以前的版本,差异化并看到谁修改了什么(参见大多数VCS的指责/注释工具 - 它打印出一个文本文件,显示何时/谁修改了文本文件中的每一行)。
其次,您可以从问题跟踪/任务跟踪中受益。
其他好处包括从互联网访问网页,拥有维基(在某些情况下可能很棒)等。
我在工作中使用Subversion + Redmine,我发现它非常有用 - 测试一些解决方案,你一定会找到更多的优势。
答案 2 :(得分:0)
在文档管理工具的更改中可以忽略的一件事是需要围绕存储的数量进行规划以及信息体系结构问题,例如不同内容最终会在哪里结束。
如果没有一个好的计划,SharePoint特别容易设置,特别容易在事情变得繁忙时遇到困难。
我不推荐像这样的家庭成长的应用程序。这个问题已经通过现成的工具解决了,从头开始逐步增长需要付出巨大的代价,并且不会让你接近这些功能。
我是否提到规划您的安全组和文档区域(IA)有多重要?
答案 3 :(得分:0)
如果您只需要文档存储,那么sharepoint可以做得很好。 WSS是免费的,它提供了非常好的文档存储功能。
但是你必须仔细计划,因为更新现有的应用程序是痛苦的。如果您决定使用Sharepoint,那么我可以从头脑中给您一些建议
如果您尝试仅部署它并将10.000文档加载到其中,那么您以后肯定会遇到问题。如果你仔细考虑结构,那么你最终会得到非常好的文档存储。
答案 4 :(得分:0)
从长远来看,迁移很可能是值得的。您将获得可靠性,版本控制,可追溯性和可扩展性。
请务必首先确定组/权限,并确定需要修复哪些链接(可能您的应用程序使用了指向共享的链接)。
SharePoint的开源替代方案是Alfresco,它对CIFS(Windows共享)也非常有用。