相关疑难解决方法(0)

我了解SQL Server 架构的功能，但最佳实践是什么？当然，它们提供了另一层安全性，并在数据库内提供数据库对象的逻辑分组，但那里的典型情况是什么？根据我的经验，我经常看不到许多定制的模式被利用。这是典型的吗？是不是应该使用自定义模式的不太频繁的场景？

命名表和视图时应该遵循什么标准？例如，将 tbl_ 之类的内容放在表名的开头是否是个好主意？我是否应该以某种方式指定代码/查找表，例如 ct_、lut_ 或代码_？还有其他的做/不做吗？

我正在使用 MS SQL Server 并且有许多带有许多表的数据库，所以如果有一些我们可以用作标准并带有一些支持理性的东西会很好。

我们有以下设置：

• 包含桌面软件使用的私有数据的多个生产数据库
• 公共网站的网络数据库，需要来自私人数据库的一些数据
• 一个中间数据库，其中包含一些从私有数据库中提取数据的视图和存储过程

目前网站登录web数据库，web数据库连接中间数据库，在生产数据库上拉取数据或执行存储过程。所有数据库都在同一个SQL实例上，整个过程使用同一个用户账号。

用户账户对web数据库和中间数据库有完全访问权限，但只能访问私有数据库的特定视图和存储过程

这真的比让公共数据库直接连接到私有数据库更安全吗？

中间数据库似乎只是为了使事情复杂化，因为使用相同的登录名访问所有数据库中的数据，并且它已经仅限于私有数据库中所需的视图/SP。我希望删除它。

我们有 3 个完全相同数据库的副本。所有 3 个数据库都有一个Users表，并且一个用户将始终存在于所有 3 个数据库中，并且具有完全相同的设置。任何时候我们想要添加或编辑用户，我们都必须更新 3 个数据库。

Users从数据库 2 和 3 中删除表并将其替换为Synonym指向数据库 1的表是否更好？

这是我能想到的优点/缺点：

优点

• 更容易维护。可以在一个位置而不是 3 个位置更新用户
• 用户 ID 将在数据库之间匹配（很重要，因为许多附加应用程序都基于用户 ID）

缺点

• 不要认为这是标准程序，所以可能会造成混淆
• 用户必须在数据库之间具有相同的设置
• （来自下面gbn 的回答）如果数据库 1 出现故障，数据库 2 和 3 也将不可用。还存在恢复时数据不一致的潜在问题

这是我正在考虑的一个选项，用于包含数据库之间相同设置的几个不同表，而不仅仅是Users表。我在示例中使用用户，因为它很容易理解。

在Stackoverflow上问了这个问题后，我想知道我所做的是正确/最佳实践的地方。

基本上，我创建的每个对象都进入一个模式，模式名称反映了用法。例如，我有模式Audit和Admin（除其他外）。

这反过来在 中没有留下任何对象dbo。这个可以吗？还有什么我需要做的吗？

我专门针对 SQL Server 询问这个问题，我可以看到多个数据库的优点是：

1. 日志更小（因此一个失控的事务不会导致其他事务（复制等）停滞）
2. 页面损坏不会影响多个应用程序（这可以使用文件组隔离吗？）

我似乎无法从单个数据库架构中找到任何好处（也许代码管理更简单）。

您选择了哪种架构，为什么？

为了便于论证，让我们假设我在单个 SQL Server 数据库中有以下表。

mySchema.Users
mySchema.Products
-- 
secondSchema.Users
secondSchema.Contracts
secondSchema.ContractItems
--
oldSchema.People
oldSchema.Table1
oldSchema.Table2
oldSchema.Table3
oldSchema.Table4
-- 
and so on and so forth

每个“模式”都完全独立于其他“模式”。它们位于单个数据库中的唯一原因是托管和成本限制。在一个完美的世界中，这些本来应该在单独的数据库中。

当（如果有的话）我需要将 secondSchema 移动到一个新数据库时，我需要做什么，这完全是因为它的使用量增加了，现在需要将它存放在自己的数据库中。

我已经查看了关于何时使用非 dbo 模式与新数据库的决策标准，正如我上面所说的，它们在同一个数据库中没有关系或事务的理由。他们在那里是出于成本原因。