SQL ifadelerini daha sonra çalıştırmak için bir tabloya kaydetmek kötü bir fikir mi?

Daha sonra çalıştırmak için SQL deyimlerini MySQL tablosunda kaydetmek kötü bir fikir mi? SQL ifadeleri yürütmeye hazır olacak, örneğin, takas edilecek herhangi bir parametre olmayacak, örneğin DELETE FROM users WHERE id=1.

Sanırım tembel oluyorum ama bu düşünceyi düşündüm çünkü düzenli aralıklarla SQL deyimlerini yürütecek epeyce cron işleri gerektiren bir proje üzerinde çalışıyorum.

İstediğiniz şey buysa güvenlidir. Verilerinizin güvenliğiyle, güvenliğiniz konusunda dikkatli olduğunuz sürece.

Ancak tekerleği yeniden icat etmeyin, Saklı İşlemler bir tabloda depolanan SQL bitleridir. Ve destekler, teşvik eder, parametreleştirir.

Ayrıca, güvenliğinizi daha basit hale getirebilir VE arızalı nokta sayısını azaltabilir ve cron yerine MySql Etkinlik Zamanlayıcı'yı kullanarak ağ iletişimini azaltabilirsiniz .

Diğer veritabanları, iyi bir sebepten dolayı bunlarla eşdeğerdir. Bu işlevselliğe ihtiyaç duyan ilk kişi siz değilsiniz.

Daha sonra çalıştırılmak üzere SQL ifadelerini bir veritabanına kaydetmek istiyorsanız, bunları bir tabloya koymaktan daha iyi bir seçenek var: bu amaç için sağlanan yerleşik işlevselliği kullanın. Bunları saklı yordamlara yerleştirin.

Hayır, bunun iyi bir fikir olmadığını söyleyebilirim.

Bu, her "gerçek" sorgu / güncellemenin veritabanında 2 isabete ihtiyaç duyacağı anlamına gelir - biri "gerçek" sorgu / güncellemeyi ve diğeri yürütmek için.

Bu, küçük bir sistemde çok büyük bir sorun olmayabilir, ancak sisteminiz ne kadar fazla kullanıcı / işlem alırsa, o kadar az ölçeklenir.

Bunun, SQL'i kodunuza gömmek için bir alternatif aramaktan geldiğini tahmin ediyorum.

SQL’in Mason Wheeler’ın önerdiği gibi saklı bir prosedürle saklanması, bu fikirden çok daha iyi bir yol olabilir.

Üzgünüm, bunun iyi bir fikir olduğunu sanmıyorum.

Söz konusu tablonun değiştiği durumu düşünün. Senin Say id sütunu olarak değiştirildi alır new_id .

Değişimin yanı sıra, kodunuzun artık çalıştırılamayacak eski bir bağbozumu için yazılmış bir sürümü de var. Tabii, kod tablosunu kontrol etmeyi biliyor olabilirsiniz ancak bu başkası için hemen belli değil.

Açıkladığım gibi bir değişiklik için, tipik olarak bağımsız SQL dosyalarına, saklı yordamlara, tetikleyicilere, müşteri kodunda satır içi SQL'e (VB, C #, C ++ vb.) Bakar, ancak bakmayı düşündüğüm en son yere bakardım. veritabanı tablolarında. Her ne kadar belki şimdi yapacağım! :)

SQL'i bir tabloda depolamak için geçerli nedenler vardır. İşyerinde çalıştığım yazılım şimdi belge üretmek için bir sistem içeriyor ve belgelerin bir veritabanındaki verileri kullanarak oldukça karmaşık hesaplamaları içermesi gerekiyor. Belgeler sık ​​sık güncellenmektedir, ihtiyaç duyulan veriler ve yapılması gereken hesaplamalar bakımından sıklıkla büyük farklılıklar gösterir. SQL, temel olarak, bu hesaplamaları yapmak için bir betik dili olarak kullanılıyor ve SQL, bu belgeler için diğer bilgileri de içeren tablolarda saklanıyor. Bu belgeleri tutan insanlar programcı veya DBA değildir, ancak veritabanı şemasına aşinalar ve SQL konusunda uzmanlar. Bu SQL kodunu saklı yordamlar biçiminde tutmaları onlar için önemli olacaktır.

Tanımladığınız şey için - "... SQL deyimlerini düzenli aralıklarla yürütecek epeyce cron işleri gerektiren bir proje" - diğer yanıtlar, sizin için kullanılan DBMS için mağaza prosedürlerini veya eşdeğerini kullandığınızı önermek konusunda muhtemelen doğrudur ' kullanıyorum

SQL'i bir tabloda saklamakta saklı bir prosedürde saklamanın mantıklı olup olmadığına karar vermek için iyi bir kriter, bu SQL'i kimin koruyacağının belirlenmesidir. Kullanıcılar bu SQL'i korurlarsa, yani istedikleri zaman yazıp değiştirirlerse, o SQL'i bir tabloda depolamak tamamen iyi ve gerçekten en iyisi olabilir. Eğer geliştiriciler bu SQL'i koruyacaksa, o zaman (umarım otomatik) derleme ve yerleştirme prosedürleriniz tarafından güncellenebilecek bir biçimde saklanmalıdır, örneğin veritabanında saklı bir prosedür gibi bir nesne olarak depolanmalıdır.

Kolay çıkış , sorguları tutmak için bir .ini veya başka bir konfigürasyon lezzet dosyasına sahip olmak olacaktır. ve ayrıca bir noktada parametreleri kullanmak veya sorularınıza koşullar eklemek isteyebilirsiniz / gereksinim duyabilirsiniz (kodunuzdaki belirli bir durum için daha karmaşık şeylerle bunları artırın).

Tabii ki onları veritabanı seviyesinde tutabilirsiniz (ya bir tabloda ya da daha iyisi, saklı yordamlar olarak), ancak benim kadar tembelseniz ;-) ancak aynı zamanda performans, bir .ini dosyası ve PHP sevgili parse_ini yöntemi okumak için, gitmenin yoludur (başka bir programlama dili için gidecekseniz, kendi başınıza benzer yaklaşımlar bulmaktasınız)! Genellikle bu dosyayı uygulamanın bootloader'ında okur ve çok sayıda farklı sorgudan bahsediyorsak işleri hızlandırmak için statik bir nesnede (belki de üstte bir önbellek katmanıyla) tutardım.

SQL deyimine yalnızca bir kez gereksinim duyarsanız, örneğin, mesai saatleri dışında gerçekleştirilecek bir grup işlemi sıraya sokuyorsanız, evet, bunları bir masaya koymak çok işe yarayacaktır.

Aynı SQL deyimini belirtilen aralıklarla uygulamanız gerekirse, başkalarının bahsettiği saklı yordam yolu sizin için daha iyi bir seçim olabilir.

Bu, sormak istediğin şeyin oldukça sıradışı olduğunu ve başka bir sorunun belirtisi olabileceğini söyledi. Örneğin, bir kullanıcıyı bir veritabanından silmeyi bekliyorsanız, gerçek SQL deyimlerini kaydetmek yerine, işlemi uygulayan programlanmış bir komut dosyasını çağırmanız daha iyi olabilir. Bu şekilde SQL ve kod hiçbir zaman senkronizasyon dışında kalmaz.