Tôi bị cuốn vào một cuộc tranh luận tại nơi làm việc và tôi cần một vài lời khuyên về những Cạm bẫy có thể xảy ra mà tôi có thể nhìn thấy.
Tưởng tượng một kịch bản trong đó Trình kích hoạt được sử dụng để sao chép Bản ghi đã xóa vào Bảng kiểm toán. Kích hoạt sử dụng CHỌN *. Mọi người chỉ và hét lên và cho chúng tôi biết điều này tệ như thế nào.
Tuy nhiên, nếu một sửa đổi được thực hiện cho Cấu trúc của Bảng chính và Bảng kiểm toán bị bỏ qua thì Trình kích hoạt sẽ tạo ra lỗi cho mọi người biết bảng Kiểm toán cũng cần sửa đổi.
Lỗi sẽ được bắt gặp trong quá trình thử nghiệm trên các máy chủ DEV của chúng tôi. Nhưng chúng tôi cần đảm bảo DEV phù hợp với sản xuất, vì vậy chúng tôi cho phép CHỌN * trong Hệ thống sản xuất (chỉ kích hoạt).
Vì vậy, Câu hỏi của tôi là: Tôi đang bị thúc đẩy loại bỏ CHỌN *, nhưng tôi không biết làm cách nào khác để đảm bảo chúng tôi tự động nắm bắt các Lỗi phát triển có tính chất này, có ý tưởng nào hay đây là cách thực hành tốt nhất?
Tôi đã đưa ra một ví dụ dưới đây:
--Create Test Table
CREATE TABLE dbo.Test(ID INT IDENTITY(1,1), Person VARCHAR(255))
--Create Test Audit Table
CREATE TABLE dbo.TestAudit(AuditID INT IDENTITY(1,1),ID INT, Person VARCHAR(255))
--Create Trigger on Test
CREATE TRIGGER [dbo].[trTestDelete] ON [dbo].[Test] AFTER DELETE
NOT FOR REPLICATION
AS
BEGIN
SET NOCOUNT ON;
INSERT dbo.TestAudit([ID], [Person])
SELECT *
FROM deleted
END
--Insert Test Data into Test
INSERT INTO dbo.Test VALUES
('Scooby')
,('Fred')
,('Shaggy')
--Perform a delete
DELETE dbo.Test WHERE Person = 'Scooby'
CẬP NHẬT (câu hỏi viết lại):
Tôi là một DBA và cần đảm bảo Nhà phát triển không cung cấp các kịch bản Triển khai được suy nghĩ kém bằng cách đóng góp vào Tài liệu Thực hành Tốt nhất của chúng tôi. CHỌN * gây ra lỗi trong DEV khi Nhà phát triển bỏ qua Bảng kiểm toán (đây là mạng an toàn) để lỗi được phát hiện sớm trong quá trình phát triển. Nhưng đâu đó trong Hiến pháp SQL - bản sửa đổi thứ 2 ghi "Bạn sẽ không sử dụng CHỌN *". Vì vậy, bây giờ có một nỗ lực để thoát khỏi Mạng lưới an toàn.
Làm thế nào bạn sẽ thay thế Mạng lưới an toàn, hoặc tôi nên coi đây là cách thực hành tốt nhất cho Triggers?
CẬP NHẬT 2: (giải pháp)
Cảm ơn tất cả các ý kiến đóng góp của bạn, tôi không chắc mình có câu trả lời rõ ràng không vì đây có vẻ là một chủ đề rất Xám. Nhưng gọi chung là bạn đã cung cấp các điểm thảo luận có thể giúp các nhà phát triển của chúng tôi tiến lên phía trước với việc xác định Thực tiễn tốt nhất của họ.
Cảm ơn Daevinsự đóng góp của bạn, câu trả lời của bạn cung cấp nền tảng cho một số cơ chế thử nghiệm mà Nhà phát triển của chúng tôi có thể thực hiện. +1
Cảm ơn CM_Dayton, các đề xuất của bạn góp phần thực hành tốt nhất có thể có lợi cho bất kỳ ai đang làm lệch hướng Kiểm toán kích hoạt. +1
Cảm ơn ypercuberất nhiều, bạn đã đưa ra nhiều suy nghĩ xung quanh các vấn đề liên quan đến các bảng trải qua các hình thức thay đổi định nghĩa khác nhau. +1
Tóm lại là:
Is Select * ok in a tigger? Vâng, đó là một khu vực màu xám, đừng mù quáng tuân theo hệ tư tưởng "Chọn * là xấu".
Am I asking for Trouble? Có, chúng tôi làm nhiều hơn là chỉ thêm các cột mới vào bảng.
SELECT *lười biếng, nhưng vì bạn có lý do chính đáng để sử dụng nó nên nó có màu xám hơn màu đen và trắng. Những gì bạn nên thử là một cái gì đó như thế này , nhưng điều chỉnh nó để không chỉ có cùng số cột, mà tên cột và kiểu dữ liệu giống nhau (vì ai đó có thể thay đổi loại dữ liệu và vẫn gây ra sự cố trong db không thường bị bắt với SELECT *'mạng lưới an toàn' của bạn .
SELECT *như một mạng lưới an toàn nhưng nó sẽ không bắt được tất cả các trường hợp. Ví dụ: nếu bạn thả một cột và thêm nó một lần nữa. Điều này sẽ thay đổi thứ tự của các cột và (trừ khi tất cả các cột cùng loại), các phần chèn vào bảng kiểm toán sẽ không thành công hoặc dẫn đến mất dữ liệu do chuyển đổi loại ẩn.