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

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

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

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

模式不仅是一个很好的安全工具（足够使用它们的理由），而且对于逻辑分离也是完美的。看来这就是您正在练习的内容。

即使当前的要求不需要特殊的安全性，也要一路走下去，所有与审核相关的数据库对象都应该对数据库角色安全。如果这些对象分散在整个dbo架构中，那么您将必须对deny单个对象具有明确的权限。但是使用该Audit架构，您只需完成一个步骤即可deny。

我亲自练习使用架构。像数据库中的所有事物一样，有一种快乐的媒介。我不会为数据层的每个粒度方面创建一个架构。架构和分隔过多。但是我猜你离那还远。

一个典型的模式是基于权限的模式，所以你必须WebGUI，Desktop等的代码，这样所有对象都具有相同的任何权限从架构。

如果您有明确的用户组，则可以对此进行权限设置，但最终在某些时候会出现重叠且混乱的权限。我倾向于将用户/组检查推迟到代码内部进行某些检查，而不是权限对象：例如您拥有Admin和HR Excel用户：这些都运行Desktop代码。

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

某些代码不是公开的（例如UDF或内部proc），因此我将使用Helper架构来编写不应由客户端代码运行的代码。

最后，诸如Staging或System或的架构Maintenance有时很有用。

尽管dbo架构中没有用户对象，但用户dbo拥有所有架构。

dbo模式中没有任何对象是完美的。从我可以看出，这也不是过度使用架构-尽管“太多”是一个相当主观的问题（相当于“我的OO设计应该拥有多少个类？”）。

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

我想使用模式根据模块和使用模式来分离数据库。我发现它使理解数据库表变得非常容易，因此维护变得更加容易。我在上一个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和新手都非常容易理解数据库表。

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