在问了Stackoverflow 这个问题之后,我想知道我在哪里做的是正确/最佳实践。
基本上,我创建的每个对象都将进入一个架构,该架构名称反映了用法。例如,我有模式Audit
和Admin
(以及其他模式)。
反过来,这也不会留下任何对象dbo
。这个可以吗?还有什么我需要做的吗?
在问了Stackoverflow 这个问题之后,我想知道我在哪里做的是正确/最佳实践。
基本上,我创建的每个对象都将进入一个架构,该架构名称反映了用法。例如,我有模式Audit
和Admin
(以及其他模式)。
反过来,这也不会留下任何对象dbo
。这个可以吗?还有什么我需要做的吗?
Answers:
一个典型的模式是基于权限的模式,所以你必须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和新手都非常容易理解数据库表。