在 SSMS 中组织数据库和表

Question

这是我 4 或 5 天前提出的一个问题的转贴，回复为零。希望这次能有更多好运...

（使用 SQL Server 2008）

在接下来的几周内，我计划将 SQL Server 引入急需适当数据服务器的办公室。目前严重依赖散布在整个内部网络的松散 Excel 和 Access 文件（辅以大量难以理解的 VB 代码来进行数据操作）。

我们需要 SQL Server 来做两件事：
1. 对于将预先设计并持续捕获数据的内部数据库
2. 对于从客户端收到的数据集的临时上传，然后我们对其进行分析

我是这个办公室里唯一一个熟悉 SQL 的人。我将不得不训练其他 5 或 6 个人使用它。

现在，我的问题是：你们将如何设置数据库，以便使用 Management Studio 轻松直观地识别存储内容的位置？更准确地说：如果这是一个 Windows 文件系统，它看起来像这样：

c:\client work\client 1\piece of work 1 (db with 10 tables)\
c:\client work\client 1\piece of work 2 (db with 8 tables)\
c:\client work\client 1\piece of work 3 (db with 7 tables)\

c:\internal\accounting system\some db with 8 tables\
c:\internal\accounting system\some db with 5 个表\
c:\internal\some other system\some db with 7 tables\

等等

简而言之，我需要在视觉上按内部工作和客户工作进行划分。客户工作我需要由不同的客户分开。对于每个客户，我需要拆分不同的不同工作集。 （内部工作遵循类似的模式）。

我知道的解决方案：

• 运行多个数据服务器（例如，一台内部服务器，一台用于客户端工作）。不知道这样做的缺点是什么
• 为表分配架构

我很想听听你的建议！

Answer 1

您用于管理 SQL Server 的组织工具是实例、数据库和架构：

一个服务器可以运行多个实例。实例基本上是同一台机器上完全独立的服务器实例。

一个实例可以管理多个数据库。数据库是完整性的标准边界 - 您（通常）备份整个数据库，引用完整性被限制在同一数据库中的对象之间，等等。

每个数据库可以包含多个模式，让您可以组织代码。

所有这些“容器”都以某种方式与安全相关。

我建议您首先获取组织数据并处理清单，以便了解您正在处理哪些数据、谁使用这些数据以及如何使用这些数据 - 特别注意公开或协作的数据（某些人一起使用的数据） ) 并且需要划分访问权限（仅由特定角色使用）。 SQL Server 并不是存储非结构化数据的最佳选择 - 例如，我不会将其视为文件服务器的简单替换。

从那里开始为您的用户定义角色。拥有角色比为单个用户分配权限要好得多。它记录了访问的语义含义（任何执行此角色的人都需要此访问，而不是用户的身份 - john 和 kate 需要访问 - 这不会告诉您他们为什么需要访问）。确保角色足够细化。像 AccountsReceivable 这样的部门角色不如 PaymentApprover 或 InvoiceProcessor 或 AccountsSupervisor 有用。用户可以扮演多个角色 - 这将为您的基础架构提供更多的自我记录能力，并减少安全漏洞和令人头疼的问题。

这应该有助于定义您将需要哪些容器以及从那里授予和指导您的数据基础架构的访问权限。

就为用户提供直接访问权限而言，我支持 Randy Minder，SQL Server 充其量只是一个专家级用户工具。如果他们熟悉 Access，一个不错的选择是让他们针对 SQL Server 中精心设计和选择的视图使用 Access，直到他们准备好采用更系统的数据工程方法。

Answer 2

IMO，您数据库的用户不必知道或关心您的数据库的设置位置或方式。除非他们受过良好的 SQL 培训，否则不应授予他们访问 SSMS 的权限。这是一场等待发生的灾难。您应该创建允许用户访问他们需要的数据的应用程序和/或报告。这样他们就不会关心数据的位置，也不需要知道。