Sql Server需要架构(Schema)的真实原因

        一直以来，不知道Sql Server为什么搞出一个架构(Schema)的概念。数据库本身不就是一个架构吗？为什么还要费神费力弄出一个架构(Schema)呢？前几天终于有点明白了。

        设想有一系统S1, 使用一数据库Db1, 另有一系统S2, 使用数据库Db1 和 Db2。S1 只操作 Db1；S2 同时操作 Db1 和Db2。系统S2知道系统S1的存在，并且需要自己的一些数据，所以创建了Db2以存放自己的数据。系统S1使用用户U1，系统S2使用用户U2，U1拥有Db1的访问权，U2拥有Db1和Db2的访问权，系统S1不知道Db2和系统S2的存在。S2 的日常操作也是在事务包装下的，并不会造成 Db1和Db2的数据不一致。S1和S2并行运行，工作良好。
        直到有一天，硬件系统发生了严重故障，这时Db1 和 Db2进行日志回滚。单独检查Db1和Db2的数据，没有任何问题。
        但是，Db1和Db2的数据一致性现在可能就有问题了，因为Db1 和Db2 的回滚之间没有任何同步机制。在一个涉及Db1和Db2的复杂事务中，Db1的数据可能已写入，没有被丢弃，而Db2中的数据可能在回滚时被丢弃了；反之亦然，于是产生了一致性问题。

        这时，就轮到我们的主角，架构发挥用处的时候了，建立一个大的数据库Db，Db1和Db2改成为架构S1和S2，用户U1拥有架构S1的访问权，用户U2拥有架构S1和S2的访问权。你就会发现，现在任何时候都没有一致性问题了。当数据库需要回滚的时候，因为在同一数据库中，架构S1和S2之间没有任何一致性问题。