主页 / dba / 问题 / 8511
Accepted
Stuart Blackler
Asked: 2011-11-29 16:07:30 +0800 CST

过度使用/正确使用模式？

  • 772

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

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

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

sql-server best-practices

5 个回答

  1. Best Answer

    模式不仅是一个很好的安全工具（这是使用它们的充分理由），而且它们也是逻辑分离的完美选择。看起来这就是你正在练习的。

    即使当前要求不需要特殊的安全性，也可以说，与审计相关的所有数据库对象都应该对数据库角色是安全的。如果这些对象分散在整个dbo架构中，那么您将必须显式地deny授予各个对象的权限。但是使用Audit模式，你做一个单一的deny，你就设置好了。

    我个人练习使用模式。然而，就像数据库中的所有东西一样，有一个快乐的媒介。我不会为数据层的每个细粒度方面创建模式。有太多的图式和分离之类的东西。但我猜你离那一点也不近。

    • 13

  2. 一个典型的模式是基于权限的模式，所以你有WebGUI, Desktopetc 的代码，所以所有对象都具有来自模式的相同权限。

    如果您有明确的用户组，那么您可以对此授予权限，但在某些时候您最终会获得重叠和混乱的权限。我倾向于将用户/组检查推迟到一些检查内部代码而不是权限对象：假设您有 Admin 和 HR Excel 用户：这些都运行Desktop代码。

    数据通常是共享的，所以我有一个Data模式，也许是一个History或Archive模式。

    有些代码不是公开的（如 UDF 或内部过程），所以我会Helper为不应由客户端代码运行的代码使用模式。

    最后，类似StagingorSystem或 or的模式Maintenance有时很有用。

    尽管模式中没有用户对象dbo，但用户dbo拥有所有模式。

    • 5

  3. 架构中没有对象dbo是完全可以的。从我所见，这也不是过度使用模式——尽管有多少模式是“太多”是一个相当主观的问题（它类似于“我的 OO 设计应该有多少类？”）。

    我要提到的唯一另一件事是授予架构而不是单个对象的权限（您的 SO 问题没有指定有关权限的任何内容）。

    • 4

  4. 我想根据模块和使用模式使用模式来分离数据库。我发现它使理解数据库表变得非常容易，因此维护变得更容易。我在上一个 sql server 项目中有以下模式类型。LT——查找表

    COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

    对于一个大模块，我们还将它们分成更多的模式。例如个人模块由超过 5 个模块组成。

    PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

    我们还包括了类似其他活动 TEMP、MAINTANENCE 的模式。在管理工作室中，您可以使用模式名称进行过滤。负责 MODULE1 的开发人员根据名称进行过滤，并且几乎所有时间都只使用这些表。这使得开发人员、dbas 和新手都可以很容易地理解数据库表。

    • 1

  5. sql server 的最佳实践可能与 oracle 不同，但我的经验是模式越少越好。
    我喜欢为具有特殊权限和一些代码进行维护的 dba/程序员提供一个模式。所有业务数据都应该放在一个模式中，这样您就知道它在哪里。命名约定足以区分表的使用或存储的代码。
    我可以看到一个案例，您有多个业务部门拥有不同的数据，几乎没有重叠，每个业务部门都有自己的架构。否则保持简单。

    • -1

相关问题