İlk önce SQL'de yürütülen işlevlere güvenebilir miyim

Lütfen aşağıdaki komut dosyasını göz önünde bulundurun:

create or replace function f(p_limit in integer) return integer as
begin
  set_global_context ('limit', p_limit);
  return p_limit;
end;
/

create view v as 
select level as val from dual connect by level<=sys_context('global_context','limit');

select f(2), v.* from v;

/*
F(2)                   VAL                    
---------------------- ---------------------- 
2                      1                      
2                      2                      
*/

select f(4), v.* from v;

/*
F(4)                   VAL                    
---------------------- ---------------------- 
4                      1                      
4                      2                      
4                      3                      
4                      4                      
*/

f(x)10.2'de çalıştırılan bu test senaryosunda olduğu gibi, içerik görünüm içinde okunmadan önce yürütülmeye güvenebilir miyim ?

Hayır.

Görünümünüzü, nereye göre bağlama yerine (yerine bağlanmak yerine) bağlam filtrelemesiyle yeniden yazarsanız, bağlam için önceden ayarlanmış değeri alırsınız:

create table t as 
 select rownum r from dual connect by level <= 10;

create or replace view v as 
  select r val from t where r <=sys_context('global_context','limit');

select f(2), v.* from v;

F(2) VAL
---- ---
   2   1 
   2   2 

select f(4), v.* from v;

F(4) VAL
---- ---
   4   1 
   4   2 

select f(4), v.* from v;

F(4) VAL
---- ---
   4   1 
   4   2 
   4   3 
   4   4 

Where cümlesi, sütunlar seçilmeden önce değerlendirildiğinden, işleve iletilen değer bağlam okunana kadar ayarlanmaz. Sorgunuzdaki sys_context çağrısının konumu (select, where, group by, vb.) Bu değer ayarlandığında tam olarak etkilenir.

Genel olarak konuşursak, tek bir SQL ifadesini değerlendirirken DBMS'nizin bir şeyler yapacağı sıra hakkında güvenli bir şekilde hiçbir şey üstlenemezsiniz. Bu nedenle birçok DBMS, bu şekilde kullanılan işlevlerin yan etkilere sahip olmasına izin vermez (örn. MSSQL, işlevlerin orada yaptığınız genel / bağlantı durumunu ayarlamasına veya tablo içeriğini değiştirmesine izin vermez). Bir dizi ifade, bir adımdan diğerine mantıklı bir şekilde yürütülmelidir (yani, seri olarak çalıştırılırlar veya olmadıklarını söyleyemeyeceğiniz bir şekilde), ancak tek bir ifade içinde sorgu planlayıcısı zaten bulunmadığı yerlerde belirsizlik getirmediği sürece serbest saltanatı vardır (örneğin, işlevde bir yan etkisi olduğu için belirsizlik zaten vardır).

Sorgu planlayıcısı, görünümün işlevin yan etkilerinden etkilendiğini algılayacak kadar parlak olsaydı, bu işlevi potansiyel olarak farklı giriş değerleriyle çağıran başka bir görünüme katılırsanız ne yapardı? Oldukça hızlı bir şekilde çok kıllı olabilir - bu tür bir şey genellikle, herhangi bir programlama bağlamında, işlevlerin kendi çıktılarının ötesinde etkileri olmamalıdır.

Bu özel örnekte, f (x) ifadesinin ilk olarak çağrılmasının pek mümkün olmadığını söyleyebilirim, çünkü ifadenin bir kısmını "görüntüleyebilir": görünümdeki sonuç kümesi, herhangi bir işlevden önce alınacaktır. döndürülecek sütunların listesi değerlendirilir. Tabii ki bu kullanılan DBMS bağlı olarak değişecektir: Ben Oracle uzmanı değilim ve test sonuçlarınız bu durumlarda ilk olarak çağrılıyor gibi görünüyor. Ancak, herhangi bir SQL ifadesi içinde yürütme sırasına tamamen güveniyorum - her zaman beklediğiniz şekilde çalışsa bile, gelecekteki revizyonlarda bunu yapmayabilir (resmi olarak yürütmenin her zaman gideceği bir yerde belgelenmedikçe) bu şekilde).

Belgeler yalnızca "Optimize Edici önce sabitleri içeren ifadeleri ve koşulları olabildiğince tam olarak değerlendirir." ( 10.2 , 11.2 ). Öncelikle belirli bir ifadeyi değerlendireceği veya bu sırayı zaman zaman değiştirmeyeceği (aynı sürümdeki yeni bir yama düzeyi?) Garanti edilmez.