özet
Bunun yapılamamasının mantıklı bir nedeni yok , ancak fayda küçük ve hemen anlaşılamayacak bazı tuzaklar var.
Araştırma sonuçları
Biraz araştırma yaptım ve iyi bilgiler buldum. 2012-08-09 17:49 GMT'de güvenilir bir birincil kaynaktan (anonim kalmak isteyen) doğrudan bir alıntıdır:
SQL ilk icat edildiğinde, SELECT yan tümcesinde hiçbir takma adı yoktu. Bu, dil 1986'da ANSI tarafından standartlaştırıldığında düzeltilen ciddi bir eksiklikti.
Dilin "prosedürel olmayan" olması amaçlanmıştır - diğer bir deyişle, nasıl bulunacağını belirtmeden istediğiniz verileri tanımlamak için tasarlanmıştır. Bu nedenle, bildiğim kadarıyla, bir SQL uygulamasının işlemden önce tüm sorguyu ayrıştırmamasının ve takma adların herhangi bir yerde tanımlanmasına ve her yerde kullanılmasına izin vermesinin bir nedeni yoktur. Örneğin, aşağıdaki sorgunun geçerli olmaması için herhangi bir neden göremiyorum:
select name, salary + bonus as pay
from employee
where pay > 100000
Bu makul bir sorgu olduğunu düşünüyorum rağmen, bazı SQL tabanlı sistemler bazı uygulama ile ilgili bir nedenden dolayı takma ad kullanımı kısıtlamaları getirebilir. SQL Server'ın bunu yaptığını duyduğuma şaşırmadım.
SQL-86 standardı ve neden modern DBMS'lerin takma adı yeniden kullanımını desteklemediğini, ancak henüz bu konuda çok fazla zaman bulamadıklarını merak ediyorum. Yeni başlayanlar için, belgeleri nereden alacağımı veya komiteyi tam olarak kimin oluşturduğunu nasıl bulacağımı bilmiyorum. Birisi yardım edebilir mi? Ayrıca SQL Server'ın geldiği orijinal Sybase ürünü hakkında daha fazla bilgi edinmek istiyorum.
Bu araştırmadan ve bazı başka düşüncelerden, diğer cümlelerde takma ad kullanmanın, mümkün olsa da, DBMS üreticileri için diğer dil özelliklerine kıyasla hiç bu kadar yüksek bir öncelik olmadığından şüphelenmeye başladım. Sorgu yazarı tarafından kolayca çözülebilen bir engel o kadar da fazla olmadığından, diğer ilerlemeler üzerinde çaba sarf etmek uygun değildir. Ek olarak, açıkça SQL standardının bir parçası olmadığı için tescilli olacaktır (bununla ilgili daha fazla bilgi edinmek için bekliyorum) ve bu nedenle DBMS'ler arasında SQL uyumluluğunu bozan küçük bir gelişme olacaktır. Karşılaştırma yapmak gerekirse, CROSS APPLY(dış referanslara izin veren türetilmiş bir tablodan başka bir şey değildir) büyük bir değişikliktir, bu arada tescilli diğer şekillerde kolayca gerçekleştirilemeyen inanılmaz ifade gücü sunar.
Diğer Adları Her Yerde Kullanmayla İlgili Sorunlar
SELECT öğelerinin WHERE yan tümcesine konmasına izin verirseniz, yalnızca sorgunun karmaşıklığını (ve dolayısıyla iyi bir yürütme planı bulmanın karmaşıklığını) patlatmakla kalmazsınız, tamamen mantıksız şeyler bulmak mümkündür. Deneyin:
SELECT X + 5 Y FROM MyTable WHERE Y = X
MyTable zaten Y sütununa sahipse, hangisinin WHERE yan tümcesi olduğunu belirtir? Çözüm bir CTE veya türetilmiş bir tablo kullanmaktır, bu da çoğu durumda ekstra maliyete neden olmamakla birlikte aynı nihai sonuca ulaşır. CTE'ler ve türetilmiş tablolar, bir takma adın yalnızca bir kez kullanılmasına izin vererek en azından belirsizliğin çözümlenmesini zorunlu kılar.
Ayrıca, FROM yan tümcesinde takma ad kullanılmaması da mantıklıdır. Bunu yapamazsın:
SELECT
T3.ID + (SELECT Min(Interval) FROM Intervals WHERE IntName = 'T') CalcID
FROM
Table1 T
INNER JOIN Table2 T2
ON T2.ID = CalcID
INNER JOIN Table3 T3
ON T2.ID = T3.ID
Bu, (T2 gizlice bu tablo artır liste olarak sunulmuştur önce, T3 bir değeri ifade anlamda) ve dairesel bir kaynaktır yama görmek zordur. Buna ne dersin:
INSERT dbo.FinalTransaction
SELECT
newid() FinalTransactionGUID,
'GUID is: ' + Convert(varchar(50), FinalTransactionGUID) TextGUID,
T.*
FROM
dbo.MyTable T
Newid () işlevinin iki kez yürütme planına ekleneceğine ne kadar emin olmak istiyorsunuz, bu iki sütunu tamamen beklenmedik bir şekilde farklı değerler gösteriyor. Yukarıdaki sorgu ne zaman CTE'lerde veya türetilmiş tablolarda N düzeylerinde kullanıldığında. Sorunun tahmin edebileceğinizden daha kötü olduğunu garanti ediyorum. Orada zaten şeyler sadece bir kez veya bir sorgu planında hangi noktada değerlendirilir zaman konusunda ciddi tutarsızlık sorunları ve Microsoft söyledi o düzeltme olmazbazıları sorgu cebirini doğru ifade ettikleri için - beklenmedik sonuçlar alırsa, sorguyu parçalara ayırın. Zincirleme referanslara izin vermek, potansiyel olarak çok uzun bu tür zincirlerle dairesel referansları tespit etmek - bunlar oldukça zor problemlerdir. Paralellik tanıtmak ve yapımında bir kabus var.
Not: Diğer adın WHERE veya GROUP BY içinde kullanılması newid () veya rand () gibi işlevlerle ilgili sorunlarda bir fark yaratmayacaktır.
Yeniden kullanılabilir ifadeler oluşturmanın bir SQL Server yolu
ÇAPRAZ UYGULAMA / DIŞ UYGULAMA, SQL Server'da sorguda başka herhangi bir yerde kullanılabilen ifadeler oluşturmanın bir yoludur (FROM yan tümcesinde daha önce değil):
SELECT
X.CalcID
FROM
Table1 T
INNER JOIN Table3 T3
ON T.ID = T3.ID
CROSS APPLY (
SELECT
T3.ID + (SELECT Min(Interval) FROM Intervals WHERE IntName = 'T') CalcID
) X
INNER JOIN Table2 T2
ON T2.ID = X.CalcID
Bu iki şey yapar:
- ÇAPRAZ UYGULAMADAKİ tüm ifadelerin bir "ad alanı" (bir tablo diğer adı, burada, X) almasını ve bu ad alanı içinde benzersiz olmasını sağlar.
- Her yerde sadece CalcID'in X'den geldiğini değil, aynı zamanda T1 ve T3 tablosuna katılırken neden X'ten bir şey kullanamayacağınızı açıkça ortaya koyuyor, çünkü X henüz tanıtılmadı.
Aslında CROSS UYGULAMAYA oldukça düşkünüm. Benim sadık dostum oldu ve ben her zaman kullanıyorum. Kısmi UNPIVOT'a mı ihtiyacınız var (yerel sözdizimini kullanan bir PIVOT / UNPIVOT veya UNPIVOT / PIVOT gerektirir)? ÇAPRAZ UYGULAMA ile yapılır. Birçok kez yeniden kullanılacak hesaplanmış bir değere mi ihtiyacınız var? Bitti. Bağlı bir sunucu üzerinden çağrılar için yürütme sırasını sıkı bir şekilde zorlamanız mı gerekiyor? Hızda çığlık atan bir iyileştirme ile bitti. Sadece 2 sıraya bölünmüş veya fazladan bir sıraya mı ihtiyacınız var? Bitti.
En azından, DBMS SQL Server 2005 ve sonraki sürümlerde, şikayet için başka bir nedeniniz yok: ÇAPRAZ UYGULAMA, istediğiniz şekilde KURUsunuz.