情景展现：

某夜小熊跑到Q上：呼叫发哥，呼叫发哥，我按逐浪官网的操作，建了一个标签，可怎么也调不出数据，怎么办？

发哥：你确认库中有这个表吗？

小熊：是啊，有表，您看。

发哥：那你把库备份发过来我查一下。

#￥（@（*#@#*（@&*（#@）！@

捣腾半天，找不到表。

小熊：不会吧，我这真的有表啊，你看截图：

发哥：哦，偶滴神啊，这就是可怜的架构问题。。。。。。于是就引入了本文正文。

 一、架构、表、视图三者关系

作为一个标准的数据库，一个数据库包括架构、表、视图三个关键元素，这三者是互相独立的，并非虚无飘缈。
中小型应用中，架构一般都采用默认架构，如dbo，所以很多时候都是省略了，而MSSQL会以默认的方式读取、查询。也正是由于大多时候，站长和开发者们不会注意到架构的存在，所以一遇到这样的架构问题时，就会脚忙手乱，甚至是无从下手。
Zoomla!逐浪CMS作为面向大型门户开发的内容内核系统，即使在执行普通的标签查询时，也会采用标准的架构，如下所示：
 

zoomladb.dbo.ZL_User left join zoomladb.dbo.ZL_UserBase on zoomladb.dbo.ZL_User.UserID=zoomladb.dbo.ZL_UserBase.UserID

上面的一段语句中，作为逐浪CMS的初始数据查询，就将库名、架构、表名三者准确无误的表达出来了，显然是标准的写法。

所以，初学数据库者要注意的是，不要以为你的数据库中存在某表，就认为一切大吉了，这当然是不可以的。

那么，如果数据库中的表架构出现错误引用，并非为dbo引用，那应该如何处理？

其实大不用急，下面分享几个有用的SQL语法可以为您解决此问题（即将数据表转为默认DBO引用）：

脚本一：

--执行如下SQL语句

ALTER   AUTHORIZATION   ON   SCHEMA::db_owner   TO   dbo;
--然后手动删除就可以了

脚本二：

--将下面的代码在查询分析器中执行，修改修改库名

use 你的库名
go

declare tb cursor local
for
select 'sp_changeobjectowner '
+quotename(
+quotename(user_name(uid))
+'.'+quotename(name),'''')
+',''dbo'''
from sysobjects
where objectproperty(id,N'isusertable')=1
and uid<>user_id('dbo')
declare @s nvarchar(4000)
open tb
fetch tb into @s
while @@fetch_status=0
begin
exec(@s)
fetch tb into @s
end
close tb
deallocate tb
 

事实上，上面的问题也适用于数据库迁移时删除孤立用户提示：“数据库主体在该数据库中拥有 架构,无法删除”的解决方法，百试不爽，不妨一试：）

学习心得：同一个数据库中，不同的架构引用的表是不同的，而同一服务器端，同样也可以拥有不同的MSSQL实例，这二者道理其实是互通的，只是大多数人没注意。

 二、如何正确的配置MSSQL数据库权限

作为MSSQL企业级数据库应用，其安全性策略是值得开发者深入研究的。

有一些同行厂商，面向中低端用户，仅仅单方面从易用角度考虑，告诉用户在连接数据库时只要采用“SA”连接即可。

事实上，在安全的服务器中，SA帐号很多时候是禁用或超安全加密的。

而前不久有一批从传统ASP厂商佛山动易CMS转来的客户中，居然说“动易官方的教程就是引导用户采用SA来配置网站用户安全的“。

这种把内裤当外衣的穿法，虽然不致于触犯天条（最多只是安全性大打折扣），但却是极对客户不负责的，我们在此也呼吁同行厂商在作培训的时候，多对安全性给予关注。

在逐浪CMS中，对于安全的防范，不仅作到有专用的方法屏蔽无效字符和注入，甚至在每一条SQL语句的引用，都做了精准严谨的分析，以求不存在安全瑕疵。

在大型站点开发过程中，有什么比安全更重要呢？

唯谨慎极致，做用户最放心的产品，构建卓越的zoomla!逐浪CMS是我们的毕生追求！