公司 Intranet 的 SharePoint 站点层次结构 - 具有一个根的多个站点或子站点？

发布于 2024-10-08 15:49:50 字数 525 浏览 0 评论 0原文

我是一家中型制造公司的 IT 经理。我们正在尝试使用 SharePoint - 到目前为止，我们已经在生产环境中使用了一个博客>这是首席执行官的。

我们有几个基于列表的“应用程序”的用例，以及一些简单的工作流程，将由我们的一位开发人员实施。我们还希望让我们的用户（至少是更精通技术的用户）能够创建和使用自己的部门网站。

然而，我们担心我们可能会开始一些如果被广泛采用的话可能很快就会失控的事情（这将是一件好事）。由于我们并不真正了解所有的架构权衡，因此我们最终可能会在一个让我们陷入困境的结构中得到大量的用户数据。

我们最大的问题是，每次使用是否需要多个站点，而不是只有一个根站点（其他所有内容都源自该根站点）。多个站点将使我们能够灵活地进行更改或开发新功能，而不会给所有用户带来问题。但是，多个站点可能更难以备份、搜索和维护用户配置文件/安全性。单一的大型站点似乎会扭转成本/收益。

如果您能提供有关“一与多”权衡的任何见解，或者讨论该问题的资源链接，我将不胜感激。指向一般 SharePoint“企业最佳实践”（抱歉）的链接也将不胜感激。

谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

泪是无色的血 2024-10-15 15:49:50

但是，多个站点可能会更困难
备份、搜索和维护用户
配置文件/安全性。单个巨量
网站似乎扭转了
成本/收益。

我认为这是不正确的。首先，我们需要澄清，当我们说多个网站时，我们指的是多个网站集还是多个网站 - 它们是两个完全不同的东西。

现在，即使它们是多个不同的网站集，在 SQL 数据库中，它们也只是一个数据库，因为该数据库是作为 Web 应用程序级别而不是网站级别创建的。

那是关于备份的。

谈到搜索和用户配置文件，您的假设又是错误的。搜索和用户配置文件是共享服务，只要驻留在单个共享服务提供商中，它们就可以正常工作。两者都是农场级服务。

单个大型网站（如果您真的指的是这里的网站而不是网站集）是完全禁忌的，也是一个糟糕的设计。

我建议拥有多个网站集（例如公司的整体部门，如人力资源、财务、IT），然后在其下添加子站点。这样，您就可以管理一个 SQL 数据库，并且仍然可以通过向现有 Web 应用程序添加内容数据库来进行扩展。

在这里，我再次假设您正在公司级别创建拓扑。如果这是在较低水平，则需要改进。

在继续阅读任何一篇之前，请先阅读 Technet 上有关分类和站点架构的一些文章。

规划 SharePoint Server 2010 工作表
http://technet.microsoft.com/en-us/library/cc262451.aspx

规划网站和网站集
http://technet.microsoft.com/en-us/library/cc263267.aspx

网站和网站集概述
http://technet.microsoft.com/en-us/library/cc262410.aspx

规划网站导航
http://technet.microsoft.com/en-us/library/cc262951.aspx

However, multiple sites might be harder
to back-up, search, and maintain user
profiles/security. A single massive
site seems to reverse the
cost/benefits.

I would consider this as incorrect. First we need to clarify when we say multiple sites, do we mean multiple site collections or multiple sites - they are two entirely different things.

Now even if they are multiple different site collections, in SQL database, they are just one database, since the database is created as web application level and not site level.

That was regarding backup.

Coming to search and user profiles, again your assumption is wrong. Search and User Profiles are Shared SErvices and they work fine as long as they reside in single Shared Services Provider. Both are farm level services.

A single massive site is (if you really mean site here not site collection) is a complete no-no and a bad design.

I would recommend having multiple site collections (something like Overall department in your company like HR, Finance , IT) and then have subistes under it. This way you have one database in SQL to manage and still you can scale by adding content database to existing web application.

Again here, I assume that you are creating your topology at company level. If this is at some lower level it needs to be refined.

Read some articles on taxonomy and site architecture on Technet before going ahead with any one.

Planning worksheets for SharePoint Server 2010
http://technet.microsoft.com/en-us/library/cc262451.aspx

Plan sites and site collections
http://technet.microsoft.com/en-us/library/cc263267.aspx

Sites and site collections overview
http://technet.microsoft.com/en-us/library/cc262410.aspx

Plan site navigation
http://technet.microsoft.com/en-us/library/cc262951.aspx

回复收藏 0 原文

我偏爱纯白色 2024-10-15 15:49:50

这完全取决于您的需求和要求。即使有不同网站的不同网络应用程序，我也可以为您提供一个引用，以备份为优势。您可能有一些数据不经常更改的站点，例如组织策略、流程文档等。在这种情况下，进行定期备份/搜索爬行没有意义（尽管您可以选择差异备份和增量爬行，但仍然需要一周或两周一次）您必须进行完整备份）。因此我建议仔细分析您的需求然后做出决定。 Microsoft 提供了一份用于规划目的的清单和模板。 madhur 的回复中提供了一些链接，其余的你可以谷歌搜索。

回复收藏 0 原文

~没有更多了~