Là cơ sở dữ liệu kích hoạt ác? [đóng cửa]

Là cơ sở dữ liệu kích hoạt một ý tưởng tồi?

Theo kinh nghiệm của tôi, chúng là xấu xa, bởi vì chúng có thể dẫn đến các tác dụng phụ đáng ngạc nhiên, và rất khó để gỡ lỗi (đặc biệt là khi một kích hoạt bắn một cái khác). Thông thường các nhà phát triển thậm chí không nghĩ đến việc tìm kiếm nếu có một kích hoạt.

Mặt khác, có vẻ như nếu bạn có logic phải xảy ra ngoài giờ thì một cái mới FOOđược tạo ra trong cơ sở dữ liệu thì nơi dễ đánh lừa nhất để đặt nó là một trình kích hoạt chèn trên bảng FOO.

Lần duy nhất chúng tôi sử dụng kích hoạt là cho những việc thực sự đơn giản như cài đặt ModifiedDate.

Các vấn đề chính với kích hoạt là

• Chúng hoàn toàn toàn cầu - chúng áp dụng cho dù bối cảnh của hoạt động bảng là gì;
• Họ lén lút; thật dễ dàng để quên họ ở đó cho đến khi họ làm tổn thương bạn với những hậu quả ngoài ý muốn (và rất bí ẩn).

Điều này chỉ có nghĩa là chúng cần được sử dụng cẩn thận cho các trường hợp thích hợp; mà theo kinh nghiệm của tôi là giới hạn trong các vấn đề toàn vẹn quan hệ (đôi khi với độ chi tiết tốt hơn bạn có thể nhận được khai báo); và thường không dành cho mục đích kinh doanh hoặc giao dịch. YMMV.

Không, chúng thực sự là một ý tưởng tốt. Nếu có vấn đề với các kích hoạt cụ thể của bạn, thì bạn đã không làm đúng, nhưng điều đó thường có nghĩa là có vấn đề với việc triển khai của bạn, không phải là khái niệm về trình kích hoạt :-).

Chúng tôi sử dụng kích hoạt rất nhiều vì nó đặt hoạt động cụ thể của DBMS dưới sự kiểm soát của cơ sở dữ liệu nơi nó thuộc về. Người dùng DBMS không cần phải lo lắng về loại công cụ đó. Tính toàn vẹn của dữ liệu nằm trong chính cơ sở dữ liệu, không phải các ứng dụng hoặc người dùng sử dụng nó. Không có ràng buộc và kích hoạt và các tính năng khác trong cơ sở dữ liệu, các ứng dụng còn lại để thực thi các quy tắc và chỉ cần một ứng dụng / người dùng lừa đảo hoặc lỗi để phá hủy dữ liệu.

Ví dụ: không có trình kích hoạt, những điều kỳ diệu như cột được tạo tự động sẽ không tồn tại và bạn phải xử lý một hàm trên mỗi hàng khi chọn chúng. Điều đó có khả năng giết chết hiệu suất DBMS, tốt hơn nhiều để tạo cột được tạo tự động tại thời điểm chèn / cập nhật vì đó là lần duy nhất nó thay đổi.

Ngoài ra, việc thiếu các trình kích hoạt sẽ ngăn các quy tắc dữ liệu được thi hành tại DBMS như các trình kích hoạt trước để đảm bảo các cột có định dạng cụ thể. Lưu ý rằng điều này khác với các quy tắc toàn vẹn dữ liệu thường chỉ là tra cứu khóa ngoại.

Công cụ không bao giờ là xấu xa. Ứng dụng của những công cụ đó có thể là xấu xa.

Tôi đồng ý. Các vấn đề với kích hoạt là người, không phải kích hoạt. Mặc dù cần phải xem xét nhiều hơn, để xem xét và tăng cường trách nhiệm cho các lập trình viên kiểm tra mọi thứ một cách chính xác, chúng tôi không loại bỏ các chỉ mục để làm cho cuộc sống của chúng tôi đơn giản hơn. (Các chỉ mục xấu có thể tệ như các trình kích hoạt xấu)

Tầm quan trọng của các kích hoạt (trong suy nghĩ của tôi) là ...
- Bất kỳ hệ thống nào cũng phải luôn ở trạng thái hợp lệ
- Mã để thực thi trạng thái hợp lệ này phải được tập trung (không được ghi trong mỗi SP)

Từ quan điểm bảo trì, một trình kích hoạt rất hữu ích cho các lập trình viên và các vấn đề đối với những người thiếu niên / nghiệp dư hơn. Tuy nhiên, những người này cần phải học hỏi và phát triển bằng cách nào đó.

Tôi đoán nó đi xuống môi trường làm việc của bạn. Bạn có những người đáng tin cậy học tốt và có thể được tin tưởng để có phương pháp? Nếu không, bạn dường như có hai lựa chọn:
- Chấp nhận rằng bạn sẽ phải mất chức năng để bù lại
- Chấp nhận rằng bạn cần những người khác nhau hoặc đào tạo và quản lý tốt hơn

Họ có vẻ khắc nghiệt, và tôi đoán rằng họ là. Nhưng đó là sự thật cơ bản, trong tâm trí tôi ...

Tôi nghĩ rằng kích hoạt không chỉ không xấu, mà còn cần thiết để thiết kế cơ sở dữ liệu tốt. Các lập trình viên ứng dụng nghĩ rằng cơ sở dữ liệu chỉ bị ảnh hưởng bởi ứng dụng của họ. Họ thường sai. Nếu tính toàn vẹn dữ liệu được duy trì bất kể sự thay đổi dữ liệu đến từ đâu, kích hoạt là một yêu cầu và thật ngu ngốc khi tránh chúng bởi vì một số lập trình viên quá dân tộc để xem xét rằng một cái gì đó ngoài ứng dụng được đánh giá cao của họ có thể ảnh hưởng đến mọi thứ. Không khó để thiết kế hoặc kiểm tra hoặc khắc phục sự cố kích hoạt nếu bạn là nhà phát triển cơ sở dữ liệu có thẩm quyền. Cũng không khó để xác định rằng một trình kích hoạt đang gây ra một kết quả không mong muốn nếu nó xảy ra với bạn (như nó đối với tôi) khi nhìn vào đó. Nếu tôi gặp lỗi khi nói bảng mà tôi không tham chiếu trong sp của mình có lỗi FK, Tôi biết mà không cần suy nghĩ về nó mà kích hoạt đang gây ra vấn đề và vì vậy bất kỳ nhà phát triển cơ sở dữ liệu có thẩm quyền nào cũng vậy. Chỉ đưa các quy tắc kinh doanh vào ứng dụng là nguyên nhân số một mà tôi đã tìm thấy dữ liệu xấu vì những người khác không biết rằng quy tắc đó thậm chí còn tồn tại và vi phạm nó trong các quy trình của họ. Các quy tắc tập trung vào dữ liệu thuộc về cơ sở dữ liệu và các trình kích hoạt là chìa khóa để thực thi các quy tắc phức tạp hơn.

Chủ yếu là có.

Khó khăn với một kích hoạt là nó làm công cụ "đằng sau lưng của bạn"; nhà phát triển duy trì ứng dụng có thể dễ dàng không nhận ra nó ở đó và thực hiện các thay đổi làm hỏng mọi thứ mà không hề hay biết.

Nó tạo ra một lớp phức tạp mà chỉ cần thêm công việc bảo trì.

Thay vì sử dụng một trình kích hoạt, một thủ tục / thói quen được lưu trữ, thường có thể được thực hiện để làm điều tương tự, nhưng theo cách rõ ràng và có thể duy trì - gọi một thói quen được lưu trữ có nghĩa là nhà phát triển có thể nhìn vào mã nguồn của nó và xem chính xác những gì đang xảy ra.

Kích hoạt là vô cùng mạnh mẽ và hữu ích, có bất kỳ số lượng kịch bản trong đó một kích hoạt là giải pháp tốt nhất cho một vấn đề.

Chúng cũng là một công cụ "hack" rất tốt. Thường có những tình huống mà bạn không kiểm soát được ngay cả mã và cơ sở dữ liệu. Nếu bạn phải đợi 2 tháng để phát hành mã tiếp theo, nhưng bạn có thể áp dụng một bản vá cho cơ sở dữ liệu của mình ngay lập tức sau đó bạn có thể đặt một kích hoạt trên một bảng để thực hiện một số chức năng bổ sung. Sau đó, khi có thể phát hành mã, bạn có thể thay thế trình kích hoạt này bằng phiên bản được mã hóa của cùng chức năng nếu muốn.

Vào cuối ngày, mọi thứ đều "xấu xa" nếu bạn không biết nó đang làm gì. Quyết định kích hoạt là bởi vì có những nhà phát triển không hiểu họ cũng giống như lập luận rằng xe hơi là xấu xa vì một số người không thể lái ...

Kích hoạt có công dụng của chúng - ghi nhật ký / kiểm toán và duy trì ngày "sửa đổi lần cuối" là hai cách sử dụng rất tốt đã được đề cập trong các câu trả lời trước.

Tuy nhiên, một trong những nguyên lý cốt lõi của thiết kế tốt là các quy tắc kinh doanh / logic kinh doanh / bất cứ điều gì bạn muốn gọi nó nên được tập trung ở một nơi duy nhất. Đặt một số logic trong cơ sở dữ liệu (thông qua kích hoạt hoặc procs được lưu trữ) và một số trong ứng dụng vi phạm nguyên tắc đó. Sao chép logic ở cả hai nơi thậm chí còn tồi tệ hơn, vì chúng sẽ luôn luôn không đồng bộ với nhau.

Ngoài ra còn có vấn đề "nguyên tắc ít bất ngờ nhất" đã được đề cập.

Triggers là một công cụ tốt khi được sử dụng đúng cách. Đặc biệt cho những thứ như thay đổi kiểm toán, bảng tổng hợp, v.v.

Bây giờ chúng có thể là "ác quỷ" nếu bạn kết thúc trong "địa ngục kích hoạt" với một kích hoạt khởi động các kích hoạt khác. Tôi đã từng làm việc trên một sản phẩm COTS nơi họ có cái mà họ gọi là "kích hoạt flex". Các kích hoạt này đã được lưu trữ trong một bảng khi các chuỗi sql động được biên dịch mỗi khi chúng được thực thi. Các trình kích hoạt được biên dịch sẽ thực hiện tra cứu và xem liệu bảng đó có bất kỳ trình kích hoạt flex nào để chạy hay không, sau đó biên dịch và chạy trình kích hoạt "flex". Về lý thuyết, điều này nghe có vẻ là một ý tưởng tuyệt vời bởi vì sản phẩm dễ dàng được tùy chỉnh nhưng thực tế là cơ sở dữ liệu đã bùng nổ khá nhiều do tất cả các biên dịch mà nó phải làm ...

Vì vậy, yeah, chúng thật tuyệt nếu bạn giữ những gì bạn đang làm trong phối cảnh. Nếu nó là một cái gì đó khá đơn giản như kiểm toán, tóm tắt, tự động sắp xếp, vv, không có thăm dò. Chỉ cần ghi nhớ tốc độ tăng trưởng của bảng và cách kích hoạt sẽ ảnh hưởng đến hiệu suất.

Ở mức cao, có hai trường hợp sử dụng cho trình kích hoạt1

1) Để làm cho công cụ "tự động" xảy ra. Trong trường hợp này, các trình kích hoạt gây ra hiệu ứng phụ, chúng thay đổi dữ liệu theo cách không được mong đợi khi đưa vào toán tử (nguyên thủy), cập nhật hoặc xóa đã được thực thi và khiến trình kích hoạt kích hoạt.

Sự đồng thuận chung ở đây là kích hoạt thực sự có hại. Bởi vì chúng thay đổi ngữ nghĩa nổi tiếng của một câu lệnh INSERT, UPDATE hoặc DELETE. Việc thay đổi ngữ nghĩa của ba toán tử SQL nguyên thủy này sẽ cắn các nhà phát triển khác, những người sau này trong tương lai cần phải làm việc trên các bảng cơ sở dữ liệu của bạn không hành xử theo các cách mong đợi nữa khi được vận hành theo chúng với các nguyên hàm SQL.

2) Để thực thi các quy tắc toàn vẹn dữ liệu, ngoài các quy tắc chúng ta có thể xử lý theo cách khai báo (sử dụng KIỂM TRA, KHÓA CHÍNH, KHÓA ĐỘC ĐÁO và KHÓA NGOẠI TỆ). Trong trường hợp sử dụng này, tất cả các kích hoạt thực hiện là dữ liệu QUERY (CHỌN) để xác minh xem sự thay đổi đang được thực hiện bởi INSERT / UPDATE / DELETE có được phép hay không. Cũng giống như các ràng buộc khai báo làm cho chúng tôi. Chỉ trong trường hợp này, chúng tôi (các nhà phát triển) đã lập trình việc thực thi.

Sử dụng kích hoạt cho trường hợp sử dụng sau không có hại.

Tôi đang viết blog về điều đó tại: http://harmfultriggers.blogspot.com

Tôi biết các nhà phát triển nghĩ rằng nên kích hoạt luôn luôn được sử dụng trong đó đó là cách trực tiếp nhất để đạt được chức năng họ muốn và các nhà phát triển sẽ không bao giờ muốn. Nó gần giống như giáo điều giữa hai trại.

Tuy nhiên, cá nhân tôi hoàn toàn đồng ý với MarkR - bạn có thể (gần như) luôn viết mã có chức năng tương đương với trình kích hoạt sẽ dễ thấy hơn và do đó dễ bảo trì hơn.

Không ác. Họ thực sự đơn giản hóa những thứ như

1. Đăng nhập / kiểm toán các thay đổi đối với các bản ghi hoặc thậm chí các lược đồ cơ sở dữ liệu

Bạn có thể có một kích hoạt trên ALTER TABLE để khôi phục các thay đổi trong môi trường sản xuất của bạn. Điều này sẽ ngăn chặn bất kỳ sửa đổi bảng tình cờ.

2. Tăng cường khả năng tham chiếu (mối quan hệ khóa chính / ngoại khóa, v.v.) trên nhiều cơ sở dữ liệu

Không, họ không xấu xa - họ chỉ bị hiểu lầm :-D

Kích hoạt có một sử dụng hợp lệ, nhưng quá thường xuyên như là một hack-retro cuối cùng làm cho mọi thứ tồi tệ hơn.

Nếu bạn đang phát triển DB như một phần của ứng dụng, logic phải luôn nằm trong mã hoặc sprocs thực hiện cuộc gọi. Kích hoạt sẽ chỉ dẫn đến gỡ lỗi đau sau này.

Nếu bạn hiểu cách khóa, khóa chết và cách DB truy cập tệp trên đĩa thì sử dụng trình kích hoạt đúng cách (ví dụ: kiểm tra hoặc lưu trữ truy cập DB trực tiếp) có thể thực sự có giá trị.

Nói rằng họ xấu xa là một sự tha thứ nhưng họ có thể gây ra lưới. Khi bắn một kích hoạt làm cho các kích hoạt khác bắn nó trở nên thực sự phức tạp. Giả sử chúng là rắc rối: http://www.oracle.com/t Technology / oramag / oracle / 08-sep / o58asktom.html

Làm logic kinh doanh trong Oracle với các trình kích hoạt khó hơn dường như vì nhiều vấn đề tương tranh. Bạn không thấy các thay đổi trong phiên khác cho đến khi các phiên khác cam kết.

Họ chắc chắn không xấu xa. Tôi thấy các trình kích hoạt rất quý trong quá trình tái cấu trúc các lược đồ cơ sở dữ liệu, trong khi đổi tên một cột hoặc tách một cột thành hai cột hoặc ngược lại (ví dụ: trường hợp tên / họ) và hỗ trợ quá trình chuyển đổi.

Chúng cũng rất hữu ích cho kiểm toán.

Câu trả lời này áp dụng riêng cho SQL Server. (mặc dù nó cũng có thể áp dụng cho các RDBMS khác mà tôi không biết. Tôi muốn đưa ra câu trả lời ở đây nhưng nó đã bị đóng như một bản sao của điều này.)

Một khía cạnh không được đề cập trong bất kỳ câu trả lời cho đến nay là bảo mật. Bởi vì, theo mặc định, các trình kích hoạt thực thi trong ngữ cảnh của người dùng thực thi câu lệnh khiến trình kích hoạt kích hoạt điều này có thể gây ra mối đe dọa bảo mật trừ khi tất cả các trình kích hoạt được xem xét.

Ví dụ được đưa ra trong BOL dưới tiêu đề " Quản lý bảo mật kích hoạt " là của người dùng tạo trình kích hoạt có chứa mã GRANT CONTROL SERVER TO JohnDoe ;để tăng quyền của chính họ.

Nếu có tác dụng phụ, đó là một vấn đề do thiết kế. Trong một số hệ thống cơ sở dữ liệu, không có khả năng nào khác để đặt trường tự động tức là đối với trường ID khóa chính.

Tôi nghĩ rằng họ có thể xấu xa, nhưng chỉ xấu xa như mọi thứ khác đang phát triển.

Mặc dù tôi không thực sự có nhiều kinh nghiệm với họ nhưng tôi đã có chúng trong một dự án gần đây mà tôi đã làm việc đã đưa tôi đến kết luận này. Vấn đề tôi gặp phải với họ là họ có thể khiến logic kinh doanh kết thúc ở hai địa điểm, một thư viện mã và cơ sở dữ liệu.

Tôi thấy nó là một đối số tương tự với việc sử dụng sprocs. Bạn sẽ thường có các nhà phát triển thực sự giỏi về SQL viết logic kinh doanh vào cơ sở dữ liệu, trong khi những người không có logic kinh doanh ở nơi khác.

Vì vậy, quy tắc của tôi là xem cấu trúc của dự án của bạn là gì. Nếu nó có vẻ khả thi để có logic nghiệp vụ được lưu trữ trong cơ sở dữ liệu thì việc kích hoạt nó có thể hữu ích.

Thật vậy, khá thường xuyên kích hoạt đang được sử dụng sai. Trên thực tế trong hầu hết các trường hợp, bạn thậm chí không cần chúng. Nhưng điều đó không làm cho họ nhất thiết phải xấu.

Một kịch bản xuất hiện trong đầu tôi, nơi các trình kích hoạt hữu ích là khi bạn có một ứng dụng kế thừa mà bạn không có mã nguồn và không có cách nào để thay đổi nó.

Ý tưởng kích hoạt không phải là xấu xa, hạn chế lồng nhau kích hoạt là xấu xa.