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


9

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

基本上,我创建的每个对象都将进入一个架构,该架构名称反映了用法。例如,我有模式AuditAdmin(以及其他模式)。

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


模式设计的可能重复项目-最佳做法?。及相关
gbn

Answers:


13

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

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

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


5

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

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

数据通常是共享的,所以我会有一个Data架构,也许是HistoryArchive架构。

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

最后,诸如StagingSystem或的架构Maintenance有时很有用。

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


4

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

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


我通常会在开发结束时整理权限,因为有时我们会有一些“流畅”的规范。这是怎么做的?还是在创建对象等时分配权限
Stuart Blackler

创建对象,将其分配给架构,将权限分配给架构。如果您需要开放的开发权限,只需授予对模式的完全许可权,然后再缩小范围即可。
Simon Righarts 2011年

1

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

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


2
SQL Server中的架构有所不同:数据库-架构-用户完全隔离。我发现Oracle模式受到限制
gbn
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.