SQL Tetikler ve ne zaman veya ne zaman kullanmayacağınızı

Başlangıçta SQL'i öğrendiğimde her zaman bana söylendi, yalnızca gerçekten mümkünse saklı yordamları kullanmaya ihtiyacınız varsa ve kullanmayı tercih ederseniz, tetikleyiciler kullanın.

Şimdi ne yazık ki o zamanlar (birkaç yıl önce iyi) Şu anda olduğum gibi temelleri merak edip umursamıyordum, bu yüzden nedenini sormadım.

Bu konuda toplulukların görüşü nedir? Bu sadece birinin kişisel tercihi mi, yoksa onlar için iyi bir neden olmadıkça tetikleyicilerden kaçınılması gerekir (sadece imleçler gibi).

Veritabanı tetikleyiciler üzerine Wikipedia makalesi hediyelerin iyi tetikleyiciler ne genel görünümü ve farklı veritabanlarında bunları kullanmak.

Aşağıdaki tartışma yalnızca SQL Server'a dayanmaktadır.

Tetikleyicileri kullanmak, kullanımları haklı olduğunda oldukça geçerlidir. Örneğin, her tablodaki her CRUD komutunda açık bir prosedür kodu gerektirmeden denetimde (veri geçmişini tutmak) iyi değere sahipler.

Tetikleyiciler, veriler değişmeden hemen önce ve veriler değiştirildikten hemen sonra kontrol sağlar. Bu, şunları sağlar:

• Daha önce de belirtildiği gibi denetim
• Doğrulama ve istenirse işletme güvenliği kontrolü. Bu kontrol türü nedeniyle, veri tabanına girmeden önce ve sonra sütun biçimlendirme gibi görevleri yapabilirsiniz.

Her zaman bana söylendi, yalnızca gerçekten mümkünse saklı yordamları kullanmaya ihtiyacınız varsa ve kullanmayı tercih ederseniz, tetikleyiciler kullanın.

Bunun nedenlerinden bazıları olabilir:

1. Eski günlerde tetikleyicilerin yaptığı bazı işlevler artık toplamları güncelleme ve bir sütunda otomatik hesaplama gibi başka yollarla da gerçekleştirilebilir.
2. Tetikleyicinin nerede çalıştırıldığını bilmeden, yalnızca kodu inceleyerek nerede kullanıldığını göremezsiniz. Veri değişikliklerini gördüklerinde etkilerini görüyorsunuz ve bazen masalarda bir tetikleyici ya da daha fazla harekete geçmediğini bilmediğiniz sürece değişikliğin neden olduğunu anlamak şaşırtıcı değildir.
3. CHECK, RI, birkaç masada Tetikleyiciler gibi birkaç veritabanı kontrolü kullanıyorsanız, işlem ayrıntılı akışınız anlamak ve sürdürmek için karmaşık hale gelir. Ne zaman tam olarak ne olduğunu bilmeniz gerekecek. Yine, bunun için iyi bir belgeye ihtiyacınız olacak.

Tetikleyiciler ve tetikleyici olmayan saklı yordamlar arasındaki bazı farklılıklar (diğerleri arasında):

• Tetikleyici olmayan bir saklı yordam, koddan veya bir zamanlayıcıdan veya bir toplu işden, vb. İşini yapmak için açıkça çağrılması gereken bir program gibidir; oysaki, tetikleyici, Kullanıcı tarafından doğrudan yürütülmek yerine bir olayın yanıtı. Olay, örneğin bir veri sütununda bir veri değişikliği olabilir.
• Tetikleyicilerin tipleri vardır. DDL Tetikleyicileri ve DML Tetikleyicileri (tür: INSTEAD OF, For ve AFTER)
• Tetiklemeyen Saklı yordamlar, herhangi bir nesne türüne başvurabilir, ancak bir görünüme başvurmak için INSTEAD OF tetikleyicilerini kullanmanız gerekir.
• SQLServer'da, tetikleyici olmayan saklı yordamlar üzerinde herhangi bir sayıya sahip olabilirsiniz, ancak tablo başına yalnızca 1 INSTEAD OF tetikleyici olabilir.

Tetikleyiciler, karmaşık veri bütünlüğü kuralları için bir gerekliliktir. Bunlar veritabanı dışında hiçbir yerde uygulanamaz veya veri bütünlüğü sorunlarınız olur.

Ayrıca, veritabanındaki tüm değişiklikleri (uygulamadan denetleme sorunu olan) yakalamak istemediğiniz sürece, denetim için en iyi yerlerdir.

Tetikleyiciler dikkatli bir şekilde yazılmamışsa performans sorunlarına neden olabilir ve yeterince geliştiriciler bunları iyi yazmak için yeterli bilgiye sahip değildir. Bu onların kötü raplerini aldıkları yerin bir parçası.

Tetikleyiciler genellikle veri bütünlüğünü korumak için diğer araçlardan daha yavaştır; bu nedenle bir kontrol kısıtlaması kullanabiliyorsanız, tetikleyici yerine bunu kullanın.

E-posta göndermeyi denemek gibi aptalca şeyler yapan kötü tetikleyiciler yazmak kolaydır. E-posta sunucusu çökerse gerçekten db'deki kayıtları değiştirememek ister misiniz?

SQL sunucusunda, tetikleyiciler bir kayıt yığını üzerinde çalışır. Çoğu zaman geliştiriciler, yalnızca bir kayıt ekini, güncelleştirmeyi veya silmeyi ele almaları gerektiğini düşünüyor. Bir veritabanında gerçekleşen tek veri değişikliği türü bu değildir ve tüm tetikleyiciler 1 kayıt değişikliği ve birçok kayıt değişikliği koşullarında test edilmelidir. İkinci testi yapmayı unutmak, aşırı düşük performanslı tetikleyicilere veya veri bütünlüğü kaybına neden olabilir.

Veritabanı tetikleyicilerinin kullanımı

1. Sütun değerlerini otomatik olarak yönlendirmek için.
2. Karmaşık bütünlük kısıtlamalarını uygulamak.
3. Karmaşık iş kurallarını uygulamak.
4. Karmaşık güvenlik yetkilerini özelleştirmek için.
5. Yinelenen tabloları korumak için.
6. Veri değişikliğini denetlemek.

Kişisel olarak karşılaştığım bir diğer kullanım durumu ise, birden fazla programın erişebildiği veritabanları içindir. İşlevselliği uygulamak, ancak bunun için tüm sistemleri yeniden tasarlamak istemiyorsanız, tetikleyici makul bir çözüm sunar.

Örneğin, daha önce sadece bir ofis sistemi olarak var olan bir veritabanı üzerinde çalıştım. Bir webapp bununla arayüz oluşturmak için yazıldığında, bir işlemin işlenmesi gibi çok sayıda olayın tetikleyeceği bir bildirim sistemi (örneğin stackexchange'e benzer) uygulamak istedik. Ofis arkasındaki güncellemelerin ön uç için bildirim oluşturması ve kullanıcıya işlemlerinin ofis tarafından işlendiğini bildirmesi için bir tetikleyici başlattığı için bir tetikleyici uyguladık.

Tetikleyiciler, veritabanı şeması oluşturulurken ve herhangi bir DML ifadesi sırasında uygulanamayan veritabanındaki kısıtlamaları zorlamak için kullanılabilir.

Verileri neredeyse gerçek zamanlı olarak 3. parti bir sisteme aktarmanız gerektiğini söyleyelim. Masanızda 950 gigabayt veri var, bu nedenle tüm tabloyu sadece 3. parti uygulamaya itmek için çok büyük.

Bunun yerine, sıradaki değişiklikleri biriktirirsiniz. Bazı harici programlar daha sonra düzenli aralıklarla küçük kuyruğa alınmış veri kümelerini dışarı atar.

Sistem 2000'den fazla saklı yordama sahiptir. Ayrıca kaynak kodunda tonlarca sql bulunduğunu da biliyorsunuz. Kuyruğun doğru şekilde yerleştirildiğinden emin olmak için tüm saklanan işlemleri ve kodları aramanız ve hiçbir şeyi kaçırmamanız umuduyla.

Bunun yerine kuyruğu güncel tutmak için tabloya bir tetikleyici koyabilirsiniz. Hiçbir şeyi kaçırmama garantisi. Bir merkezi konum. Performans cezası? Gerçekten değil çünkü kuyruğu doldurma isabetinin tetikleyici mi yoksa harici mi olduğu önlenemez.

Bu senaryoda, bir tetikleyici kullanmamanın kötü bir tasarım tercihi olduğunu söyleyebilirim. Daha sonra, yeni bir veri itme yöntemi kullanmak istiyorsanız (sıranın çalışmadığını söyleyin) ve tetiği kullanırsanız arayüz korunur. Tetikleyiciler genellikle en iyi seçimdir. Dogmatik anti-tetik meraklılarını dinlemeyin.

E-posta gönderen bir tetikleyici mutlaka 'aptal' bir fikir değildir. Aptal olan şey, tasarımdaki e-posta kesintisini öngörmemek ve veri kaybı olmadan incelikle ele almak değildir. Bunun 'aptal' kısmı, hata yapma konusunda bağışıklık sahibi olduklarını düşünen tembel geliştiriciler tarafından varolmayan hata yönetimi için gerçekten kötü.

Ayrıca, keyfi bir şekilde karmaşık olabilecek ve çoklu tetikleyiciler veya diğer saklı prosedürler tarafından tekrar kullanılabilecek bir saklı yordam / işlev çağrılarak bir tetikleyicinin basit tutulabileceğini de gözlemlerim. Bu yüzden paketler ve kütüphaneler var.

Bigotry gerçekten sakatlanıyor.