网络驱动器文件共享

Question

在 10 年多的时间里，我们一直依赖各种网络映射驱动器来实现文件共享。 一个驱动器号用于在团队之间共享文件，一个用于整个组织的单独文件共享，第三个用于个人使用等。我想摆脱这一点，并试图决定是否使用 ECM/Sharepoint 类型的解决方案或自制应用程序，值得付出代价和走的路吗？ 或者，由于其相对简单，我们是否应该继续依赖登录脚本/映射驱动器进行文件共享？ 有谁在自己的组织中有任何经验或对此有什么想法吗？

谢谢。

Answer 1

SharePoint 非常擅长文档共享。

文档通常遵循审批流程、拥有权限、存在于集群中……这些东西非常适合 SharePoint 文档库。

但是，有些东西不太适合在 SharePoint 中使用...您是否有想要与同事共享的虚拟硬盘 (.vhd) 文件？ 尝试将 20GB 文件放入 SharePoint 并不是一个好主意。

SharePoint 可以处理大文件，它背后的 SQL Server 也可以...但是您是否希望 SQL Server 带宽被如此大的文件饱和？ 您是否希望 SQL Server 备份多次保存如此大文件的副本？

我相信有一些 Microsoft 合作伙伴提供了将文件 blob 与 SharePoint 数据库分离的功能，以便 SharePoint 可以保存元数据，文件系统保存实际文件，SharePoint 只是成为管理访问、权限、并为整个组织的文件提供集中式界面。 这将为您提供两全其美的选择。

但现在，我认为 SharePoint 是文档的理想选择，并且我在 Windows 文件共享上保留大型文件（不以文档为中心）。

Answer 2

当然，使用工具。

这里的主要好处是版本控制。 能够轻松跳转到以前的版本，比较并查看谁修改了什么（参见大多数 VCS 的责备/注释工具 - 它打印出一个文本文件，显示何时/谁修改了文本文件中的每一行）。

其次，您可能会从问题跟踪/任务跟踪中受益。

其他好处包括从互联网访问 Web、拥有 wiki（在某些情况下这可能很棒）等。

我在工作中使用 Subversion + Redmine，我发现它非常有用 - 测试一些解决方案，您一定会发现更多信息为您带来的优势。

Answer 3

在文档管理工具的变革中，可能会被忽视的一件事是围绕将存储多少内容所需的规划以及信息架构问题（例如不同内容最终存放在哪里）。

如果没有良好的未来计划，SharePoint 的设置尤其容易，而且当事情变得繁忙时，它特别容易在以后遇到困难。

我不会推荐类似这样的自制应用程序。 这个问题已经通过现成的工具解决了，而从头开始开发一个工具将花费大量资金，并且无法让您以金钱获得任何功能。

我是否提到过规划安全组和文档区域 (IA) 有多重要？

Answer 4

如果您只需要文档存储，那么 sharepoint 可以做得很好。 WSS 是免费的，并且提供了非常好的文档存储功能。

但您必须仔细计划，因为更新现有应用程序非常痛苦。 如果您决定使用 Sharepoint，那么我可以从我的头脑中给您一些建议

1. 注意安全配置（用户组、权限等）
2. 好好规划您的文档库，因为在它们之间移动文档并不容易
3. 另外考虑限制一个文档可以拥有的版本数量，因为 sharepoint 存储版本之间的完整备份，而不仅仅是更改
4. 不要使用 infopath:) 我们对此有非常糟糕的经验（只是不要告诉经理）
5. 如果您不这样做确实不需要改变 Sharepoint 的图形外观，而不是打扰它，因为它会带来很多问题（我说的是自定义母版页和自定义站点模板）
6. 尝试使用尽可能多的 OOB 内容，因为开发自己的 Web 部件不是只会花费更多，而且可能相当复杂。
7. 确保打开搜索索引。 这是相当棘手的，因为它默认是关闭的，然后你会惊讶地发现搜索无法像我一样工作:)

如果你尝试部署它并加载 10.000 个文档，那么你肯定会遇到问题之后。 如果您稍微考虑一下结构，那么您最终将获得非常好的文档存储。

Answer 5

从长远来看，迁移可能是值得的。 您将获得可靠性、版本控制、可追溯性和可扩展性。

请务必首先确定组/权限，并确定需要修复哪些链接（也许您有使用共享链接的应用程序）。

SharePoint 的开源替代方案是 Alfresco，它对于 CIFS（Windows 共享）也非常有用。