SQL练习之不破坏应用程序现有查询的修改模式

     当我还是一个菜鸟的时候,当然现在也是,当我的软件需求发生变化时，并且数据库设计同样要求发生变化，我通常会放弃原有的代码(或者对原有的代码进行大改)，先在我知道了两个不破坏应用程序现有查询的修改模式，下面就来一个个介绍!

假设你的公司有一张记录在数据库中的设备登记表:

资产标识    描述              收到日期

50430     桌面PC           2016-5-6

50431     19寸监视器     2016-5-7

现在公司再融资之后,进行了扩张，在另一个地方又建立了新的办公室，这个时候如果简单的复制并修改原先的应用和数据库，并且在两个位置独立运行的实例是一种诱人的做法(说简单点就是再建一个用于维护新办公室信息的页面),然后这种做法虽然快速地解决了当前的问题,但是从长远的角度看会引起跟多的问题，这样我们有两个应用程序需要维护(并且这两个应用程序在功能上基本接近),所以这种方法不具有伸缩性，并且随着办公室的增加会使问题变得更加糟糕！

下面是分析列子所需的sql文件:

CREATE TABLE Equipment(
AssetTag varchar(30) not null,
Description varchar(255) null,
RequiredDate datetime null
)
INSERT INTO Equipment VALUES('50430','桌面PC',GETDATE())
INSERT INTO Equipment VALUES('50431','19寸监视器',GETDATE())

代码如下:

SELECT * 
FROM Equipment

1、通过修改表的方式完成不破坏应用程序现有查询的修改模式  代码如下:

ALTER TABLE Equipment ADD Office varchar(30) null

UPDATE Equipment
SET Office='Headquarter'

SELECT * 
FROM Equipment

这个时候,在表中添加一个新列Office,并且将现在设备表中的每一行数据都被赋值给了现在的办公室。

但是这一点都不符合大多数的实际情况,大所属情况可能是,我们将老办公室的一部分设备(用不到了的)搬到新办公室,然后老办公室被提升为总部(负责管理),这个时候只能手动去修改哪些已经被转移的设备到新的办公室！

现在我们可以插入新办公室的数据行了。然而这个时候问题又来了,原先依赖与这个表的所有查询都需要被重新检查。没有指定列的INSERT操作都会执行失败。因此,如果原来的INSERT语句为:

INSERT INTO Equipment VALUES('50431','19寸监视器',GETDATE())

DBMS会报错：列名或所提供值的数目与表定义不匹配。

但是,如果语句是:

INSERT INTO Equipment(AssetTag,Description,RequiredDate) VALUES('50430','桌面PC',GETDATE())

那么这句INSERT将会执行成功,NULL值将会被输入Office列。

可以看到,即使表以及被修改,还能是原先的查询正常的工作,但是他们会返回来自两个办公数的数据,即使我们只希望返回一个办公室的数据！

2、第二种模式通过代替表的视图来完成不破坏应用程序现有查询的修改模式

另一种方式是把现有的设备数据复制到新设计的设备表中,然后将新表中的每一行数据都归为老办公室的,如果设备有移动,那就做相应数据的更改，代码如下:

CREATE TABLE EquipmentMultiSite(
AssetTag varchar(30) not null,
Description varchar(255) null,
RequiredDate datetime null,
Office varchar(30) null
)

INSERT 
INTO EquipmentMultiSite
SELECT Equipment.*,'Headquarter'
FROM Equipment

SELECT *
FROM EquipmentMultiSite

这里如果如果设备有移动,那就做相应数据的更改！修改之后的数据就是老办公室的设备数据！

现在就可以删除Equipment表,并用一个同名的Equipment视图来替换!

DROP TABLE Equipment
go
CREATE VIEW Equipment AS
SELECT AssetTag,Description,RequiredDate
FROM EquipmentMultiSite 
WHERE Office='Headquarter'
go

这个时候,你会发现应用程序现有的查询,依然能够正常的工作，原先的办公室使用Equipment,不在乎他使用的是表还是视图,老办公室的经理现在应该能够继续利用该数据库的应用程序,但是他仅能操作(增删查该)老办公室的有关的设备。

但是对于新办公室的经理,你还需要做一些工作,你要确保Equipment关联每一个用户,这样的话,你就能为每一个用户以硬编码的方式指定正确的办公室！