使用隐藏共享创建文档管理结构的设计建议
我需要在我的软件中添加一些文档管理功能。文件将按公司名称和项目名称分组。
应用程序需要使用客户端/项目的 ID 号来访问这些文件夹，但最终用户也可以使用 Windows 资源管理器轻松浏览这些文件夹。
客户和项目将存储在数据库中。
我正在考虑让软件使用友好名称创建文件夹，然后使用带有 ID 号的隐藏共享，以便软件访问文件。
文件夹结构会是这样的
--公司 1 (公司-1234$) -- 项目 101（项目-101$） -- 项目 102（项目-102$） -- 项目 103（项目-103$） -- 公司 2（公司-5678$） -- 项目 201（项目-201$） -- 项目 202（项目-202$） -- 项目 203（项目-203$）
因此，在上面的示例中，将有一家名为“Company 1”的公司，其 ID 为“1234”。
使用 Windows 资源管理器浏览文件夹时，用户会看到
\\服务器名称\Documents\Company1
，您也可以从以下位置访问同一文件夹
\\服务器名称\Documents\Company-1234$
通过使用隐藏共享，如果公司名称更改或由于某种原因重命名，它不会破坏应用程序中的链接，因为它使用基于永不更改的 ID 的隐藏共享。
服务器上有数百个（也许数千个）或隐藏共享是否会对性能造成巨大影响？
有人有任何建议或替代方案来提供此功能吗？
I need to add some document management functionality into my software. Documents will be grouped by company name and project name.
The folders need to be accessed by the application using the id numbers of clients/projects, but also easily browsed by the end user using windows explorer.
Clients and Projects will be stored in a database.
I am thinking of having the software create the folders using the friendly name and then using a hidden share with the id number for the software to access the files.
The folder structure would be something like this
--Company 1 (Company-1234$) -- Project 101 (Project-101$) -- Project 102 (Project-102$) -- Project 103 (Project-103$) -- Company 2 (Company-5678$) -- Project 201 (Project-201$) -- Project 202 (Project-202$) -- Project 203 (Project-203$)
So in the example above there would be a company called "Company 1" with a ID of "1234".
When browsing the folders using windows explorer the user would see
\\ServerName\Documents\Company1
and you could also access the same folder from
\\ServerName\Documents\Company-1234$
By using the hidden share, if the company name changes or its renamed for some reason it doesn't break the link in the application because its using the hidden shared based on the ID that never changes.
Will having hundreds (maybe thousands) or hidden shares on a server provide a huge performance hit?
Does any one have any suggestions or alternatives to provide this feature?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您概述的解决方案对于少量共享来说通常是合理的，但是管理 1000 个共享并不是微不足道的，所以如果它变得这么大，您应该考虑使用数据库解决方案。
您将始终受到与绩效有关的一个因素的控制。无论是网络速度/容量、服务器上硬盘的速度/寻道时间等。
I think the solution you outlined is generally sound for a small number of shares but the administration of 1000s of shares is not trivial so if it gets this big you should be looking at a database solution I would say.
You will always be governed by one factor with regards to performance. Whether that be network speed/capacity, speed/seek time of hard drive on the server, etc etc.