比较SQL

newxhy

　这些年来，我发现许多开发者对于何时使用数据操纵语言（DML）触发器与何时使用约束感到迷惑。许多时候，如果没有正确应用这两个对象，就会造成问题。本文将为您何时使用约束和DML触发器提供一些启示，以帮助你避免我遇到的纠正问题。 何为约束和DML触发器？ 　约束是数据库引擎用来约束一个表或一个表关系中的数据，以维持数据库完整性的一个对象。这些约束包括CHECK、UNIQUE、PRIMARY KEY等。这里提供在TSQL中定义约束的更多细节。 　AFTER触发器是一种特殊类型的TSQL代码块，当一个DML语句根据触发器定义的表执行时，它得到执行。（在本文中我仅指这种触发器。） 何时使用约束和DML触发器 　使用约束比使用触发器更加有利（如果你可以使用约束的话）。你总是可以写出一个触发器，完成和一个约束相同的工作，但这样做一般没有什么意义。 　考虑使用一个外键约束和DML触发器。使用外键约束的目的是为了确保允许进入一个表的一列或多列的值出现在一个单独表的一列或多列中。你可以使用DML触发器建立相同的功能。 列表A建立了SalesHistory和I_SalesProducts表，我将在例子中使用它们，并给它们加载一些数据。 IF OBJECT_ID('SalesHistory')>0 DROP TABLE SalesHistory; GO CREATE TABLE [dbo].[SalesHistory] ( [SaleID] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY, [Product] [varchar](10) NULL, [SaleDate] [datetime] NULL, [SalePrice] [money] NULL ) GO DECLARE @i SMALLINT SET @i = 1WHILE (@i <=100) BEGIN INSERT INTO SalesHistory(Product, SaleDate, SalePrice) VALUES('Computer', DATEADD(mm, @i, '3/11/1919'), DATEPART(ms, GETDATE()) (@i 57)) INSERT INTO SalesHistory(Product, SaleDate, SalePrice) VALUES('BigScreen', DATEADD(mm, @i, '3/11/1927'), DATEPART(ms, GETDATE()) (@i 13)) INSERT INTO SalesHistory(Product, SaleDate, SalePrice) VALUES('PoolTable', DATEADD(mm, @i, '3/11/1908'), DATEPART(ms, GETDATE()) (@i 29))SET @i = @i 1 END GOINSERT INTO l_SalesProducts(Product) SELECT 'BigScreen' UNION SELECT 'Computer' UNION SELECT 'PoolTable' 　现在我有了一些表和一些数据可供利用，让我们在SaleHistory表中建立一个外键约束。 ALTER TABLE SalesHistory ADD CONSTRAINT fk_SalesHistory FOREIGN KEY (Product) REFERENCES l_SalesProducts(Product) [1] [2] CREATE TRIGGER tr_SalesHistory on SalesHistory FOR INSERT, UPDATE AS BEGIN IF UPDATE(Product) AND @@ROWCOUNT <> ( SELECT COUNT(*) FROM INSERTED i JOIN l_SalesProducts s ON i.Product = s.Product) BEGIN ROLLBACK TRANSACTION SELECT 'Different Results, an error has occurred.' --//THROW CUSTOM ERROR MESSAGE END END 　以这种方式建立解决方案还涉及许多工作。工作时间并不是你在创立这种解决方案时遇到的唯一问题。因为约束以SQL Server功能的形式建立，它们倾向于擅长完成它们旨在完成的工作，而且与在触发器中执行相同的功能相比，它们的表现也更好。 　当执行一个DML操作时，系统首先启动一个INSTEAD OF触发器，然后外键约束进行检查，接着再运行AFTER触发器。这表示，在调用AFTER触发器前，表中定义的任何外键约束必须得到满足。 　现在我们考虑你想要使用触发器而非约束的情况。在需要将表中的当前值与当前输入值进行比较，以不能满足某些极限时，就可以首选使用触发器。考虑下面的商业情形。 　MyCompany.com最近实施了一项商业规则，如果产品的售价低于500美元，那么一天内出售的BigScreen产品的数量就不能超过5件。此举是为了保证折扣价格不会超出公司的期望。我们来了解满足这种条件的其中一种方法。 　首先，用户界面可以查询数据库，了解输入的产品数量是否超过上限。这种方法有效，但它需要在用户界面中加入额外的商业逻辑，公司可能反对这样做。 　在这种情况下，可能很难实施一个约束，但如果要这样做，仍然需要增加一些额外的编程逻辑。应用触发器可以有效地解决这个问题，因为触发器擅长比较以往和当前的值，并根据这些值做出决策。列表C建立了实现这个目标的触发器。 CREATE TRIGGER tr_MaxProductSales ON SalesHistory FOR INSERT, UPDATE AS BEGIN DECLARE @Product CHAR(150) DECLARE @Today SMALLDATETIME DECLARE @InsertedCount INT, @CurrentCount INT DECLARE @MaxRecordCount TINYINT DECLARE @MinSalePrice MONEYIF @@ROWCOUNT > 0 BEGIN SET NOCOUNT ON SET @Today = CAST(CONVERT(VARCHAR(10), GETDATE(), 101) AS SMALLDATETIME)SET @Product = 'BigScreen' SET @MaxRecordCount = 5 SET @MinSalePrice = 500SELECT @InsertedCount = COUNT(*) FROM INSERTED WHERE Product = @Product AND SalePrice < @MinSalePrice AND SaleDate >= @Today AND SaleDate > @TodaySELECT @CurrentCount = COUNT(*) FROM SalesHistory WHERE Product = @Product AND SalePrice < @MinSalePrice AND SaleDate >= @Today AND SaleDate > @TodayIF @CurrentCount @InsertedCount > @MaxRecordCount BEGIN PRINT 'Too many product sales for today.' ROLLBACK TRANSACTION END END END 　在这个触发器中，我执行检查，看看表中更新或插入的BigSrceen产品数量，以及当天以低于500美元的售价出售的BigSrceen产品的数量是否超过5件。如果超出5件，触发器将会撤销交易，不会添加产品。 结论 　约束与DML触发器各有其优点。约束能够维护数据库表域和关系之间的数据库完整性；而触发器则擅长于比较以往和当前值，并根据这些数据做出决策。 　在我看来，一般来说，如有可能，使用约束更为有利；而将棘手的商业和审计逻辑留给触发器来解决。 　Tim Chapman是肯塔基州路易维尔市一家银行的SQL Server数据库管理员，他有超过7年的IT行业经验。他还通过了微软SQL Server 2000和SQL Server 2005的认证。 [1] [2] <