Çoklu Tablo Tablosu Değerli İşlev ve Satır İçi Tablo Değerli İşlev

Göstermek için birkaç örnek, sadece örtmek:

Satır İçi Tablo Değerli

CREATE FUNCTION MyNS.GetUnshippedOrders()
RETURNS TABLE
AS 
RETURN SELECT a.SaleId, a.CustomerID, b.Qty
    FROM Sales.Sales a INNER JOIN Sales.SaleDetail b
        ON a.SaleId = b.SaleId
        INNER JOIN Production.Product c ON b.ProductID = c.ProductID
    WHERE a.ShipDate IS NULL
GO

Çoklu Tablo Tablosu Değerli

CREATE FUNCTION MyNS.GetLastShipped(@CustomerID INT)
RETURNS @CustomerOrder TABLE
(SaleOrderID    INT         NOT NULL,
CustomerID      INT         NOT NULL,
OrderDate       DATETIME    NOT NULL,
OrderQty        INT         NOT NULL)
AS
BEGIN
    DECLARE @MaxDate DATETIME

    SELECT @MaxDate = MAX(OrderDate)
    FROM Sales.SalesOrderHeader
    WHERE CustomerID = @CustomerID

    INSERT @CustomerOrder
    SELECT a.SalesOrderID, a.CustomerID, a.OrderDate, b.OrderQty
    FROM Sales.SalesOrderHeader a INNER JOIN Sales.SalesOrderHeader b
        ON a.SalesOrderID = b.SalesOrderID
        INNER JOIN Production.Product c ON b.ProductID = c.ProductID
    WHERE a.OrderDate = @MaxDate
        AND a.CustomerID = @CustomerID
    RETURN
END
GO

Bir türün (satır içi veya çoklu deyim) diğerine göre kullanılmasının bir avantajı var mı? Biri diğerinden daha iyi olduğunda veya farklılıklar tamamen sözdizimsel olduğunda belirli senaryolar var mı? İki örnek sorgunun farklı şeyler yaptığını anlıyorum, ancak bunları bu şekilde yazmamın bir nedeni var mı?

Onlar hakkında okumalar ve avantajlar / farklılıklar gerçekten açıklanmamıştır.

Matt'in yorumunu araştırırken orijinal ifademi gözden geçirdim. Doğru, bir satır içi tablo değerli işlevi (ITVF) ve çoklu tablo değerli bir işlevi (MSTVF) arasında performans farkı, her ikisi de bir SELECT deyimi yürütseler bile. SQL Server, bir ITVF'yeVIEWsöz konusu tablolardaki en son istatistikleri kullanarak bir yürütme planı hesaplayacaktır. Bir MSTVF, SELECT ifadenizin tüm içeriğini bir tablo değişkenine doldurmaya ve sonra buna katılmaya eşdeğerdir. Bu nedenle, derleyici MSTVF tablolarda herhangi bir tablo istatistiklerini kullanamaz. Böylece, her şey eşittir (nadiren oldukları gibi), ITVF MSTVF'den daha iyi performans gösterecektir. Testlerimde, tamamlanma süresindeki performans farkı göz ardı edilebilirdi, ancak istatistik açısından bakıldığında fark edildi.

Sizin durumunuzda, iki işlev işlevsel olarak eşdeğer değildir. MSTV işlevi her çağrıldığında fazladan bir sorgu yapar ve en önemlisi müşteri kimliğini filtreler. Büyük bir sorguda, optimize edici, geçen her customerId için işlevi çağırması gerekeceğinden diğer birleştirme türlerinden yararlanamaz. Ancak, MSTV işlevinizi şu şekilde yeniden yazdıysanız:

CREATE FUNCTION MyNS.GetLastShipped()
RETURNS @CustomerOrder TABLE
    (
    SaleOrderID    INT         NOT NULL,
    CustomerID      INT         NOT NULL,
    OrderDate       DATETIME    NOT NULL,
    OrderQty        INT         NOT NULL
    )
AS
BEGIN
    INSERT @CustomerOrder
    SELECT a.SalesOrderID, a.CustomerID, a.OrderDate, b.OrderQty
    FROM Sales.SalesOrderHeader a 
        INNER JOIN Sales.SalesOrderHeader b
            ON a.SalesOrderID = b.SalesOrderID
        INNER JOIN Production.Product c 
            ON b.ProductID = c.ProductID
    WHERE a.OrderDate = (
                        Select Max(SH1.OrderDate)
                        FROM Sales.SalesOrderHeader As SH1
                        WHERE SH1.CustomerID = A.CustomerId
                        )
    RETURN
END
GO

Bir sorguda, iyileştirici bu işlevi bir kez çağırabilir ve daha iyi bir yürütme planı oluşturabilir, ancak yine de eşdeğer, parametreleştirilmemiş bir ITVS veya a'dan daha iyi olmaz VIEW.

Mümkün olduğunda ITVF'ler MSTVF'lere göre tercih edilmelidir, çünkü tablodaki sütunlardan veri türleri, nullabilite ve harmanlama, bu özellikleri çok ifadeli tablo değerli bir işlevde beyan edersiniz ve daha da önemlisi, ITVF'den daha iyi yürütme planları alırsınız. Deneyimlerime göre, bir ITVF'nin bir VIEW'dan daha iyi bir seçenek olduğu pek çok koşul bulamadım, ancak kilometre değişebilir.

Matt sayesinde.

İlave

Son zamanlarda bunu gördüğümden beri, burada Wayne Sheffield tarafından Satır İçi Tablo Değerli işlevler ve Çoklu Tablo işlevleri arasındaki performans farkını karşılaştıran mükemmel bir analiz var.

Orijinal blog yazısı.

SQL Server Central'a kopyalama

Dahili olarak SQL Server, satır içi tablo değerli bir işlevi bir görünümde olduğu gibi ele alır ve çok deyimli tablo değerli bir işlevi, saklı yordam gibi davranır.

Dış sorgunun bir parçası olarak satır içi tablo değerli bir işlev kullanıldığında, sorgu işlemcisi UDF tanımını genişletir ve bu nesneler üzerindeki dizinleri kullanarak temel alınan nesnelere erişen bir yürütme planı oluşturur.

Çok ifadeli tablo değerli bir işlev için, işlevin kendisi için bir yürütme planı oluşturulur ve yürütme planı önbelleğinde depolanır (işlev ilk kez yürütüldüğünde). Çok ifadeli tablo değerli işlevler daha büyük sorguların bir parçası olarak kullanılırsa, iyileştirici işlevin ne döndürdüğünü bilmez ve bu nedenle bazı standart varsayımlar yapar - aslında işlevin tek bir satır döndüreceğini ve işleve, tek sıralı bir tabloya karşı bir tablo taraması kullanılarak erişilir.

Çok ifadeli tablo değerli işlevlerin kötü performans gösterebildiği yerler, çok sayıda satır döndürdüğü ve dış sorgularda birleştirildiği zamandır. Performans sorunları öncelikle optimize edicinin tek bir satır döndürüldüğünü varsayarak bir plan üreteceği gerçeğine bağlıdır ve bu da en uygun plan olmayacaktır.

Genel bir kural olarak, bu potansiyel performans sorunları nedeniyle mümkün olduğunda satır içi tablo değerli işlevlerin çoklu deyim işlevlerine (UDF dış sorgunun bir parçası olarak kullanıldığında) tercih edilmesi gerektiğini bulduk.

Başka bir fark daha var. Tıpkı bir görünümde olduğu gibi, satır içi tablo değerli bir işlev eklenebilir, güncellenebilir ve buradan silinebilir. Benzer kısıtlamalar geçerlidir - toplamalar kullanılarak işlevler güncellenemez, hesaplanan sütunlar güncellenemez vb.

Örnekleriniz bence soruyu çok iyi cevaplıyor. İlk işlev tek bir seçim olarak yapılabilir ve satır içi stilini kullanmak için iyi bir nedendir. İkincisi muhtemelen tek bir ifade olarak yapılabilir (maksimum tarihi almak için bir alt sorgu kullanarak), ancak bazı kodlayıcılar bunu yaptığınız gibi birden çok ifadede okumayı daha kolay veya daha doğal olarak bulabilir. Bazı işlevler sadece bir deyimde gerçekleştirilemez ve bu nedenle çoklu deyim sürümünü gerektirir.

Mümkün olduğunca basit (satır içi) kullanmanızı ve gerektiğinde (açıkça) çoklu kişisel ifadeler kullanmanızı veya kişisel tercih / okunabilirliği ekstra yazmayı gerektirdiğinde öneririm.

Satır İçi ve Çoklu Tablo Tablosu Değerli İşlevleri Karşılaştırma konusuna bakın, iyi açıklamalar ve performans ölçütleri bulabilirsiniz

Bunu test etmedim, ancak çoklu ifade işlevi sonuç kümesini önbelleğe alır. Optimize edicinin işlevi satır içine alması için çok fazla şeyin olduğu durumlar olabilir. Örneğin, "Şirket Numarası" olarak ilettiğiniz şeye bağlı olarak farklı veritabanlarından sonuç döndüren bir işleviniz olduğunu varsayalım. Normalde, bir sendika ile bir görünüm oluşturabilir, sonra şirket numarasına göre filtreleyebilirsiniz, ancak bazen sql sunucusunun tüm sendikayı geri çektiğini ve birini seçecek kadar akıllı olmadığını gördüm. Bir tablo işlevinin kaynağı seçmek için mantığı olabilir.

Çok satırlı bir işlevi kullanmak için başka bir durum sql sunucusunun where yan tümcesini aşağı itmesini önlemek olacaktır.

Örneğin, tablo adlarına sahip bir tablo var ve bazı tablo adları C05_2019 ve C12_2018 gibi biçimlendirilmiş ve bu şekilde biçimlendirilmiş tüm tablolar aynı şemaya sahip. Tüm bu verileri tek bir tabloda birleştirmek ve 05 ve 12'yi bir CompNo sütununa ve 2018,2019'u bir yıl sütununa ayrıştırmak istedim. Ancak, ACA_StupidTable gibi CompNo ve CompYr ayıklayamaz ve denedim, bir dönüştürme hatası alacağı gibi diğer tablolar vardır. Yani, benim sorgu iki bölümden, sadece 'C_______' gibi biçimlendirilmiş tabloları döndüren bir iç sorgu sonra dış sorgu bir alt dize ve int dönüşüm yaptı. yani CompNo olarak Cast (Substring (2, 2) int olarak). Sql sunucusu sonuçlar filtrelenmeden önce Cast işlevimi koymaya karar vermesi dışında tüm iyi görünüyor ve bu yüzden bir zihin dönüştürme hatası aldım. Çoklu ifade tablosu işlevi bunun olmasını engelleyebilir,

Belki çok yoğun bir şekilde. ITVF (satır içi TVF): daha fazla DB kişisiyseniz, bir tür parametreli görünümdür, tek bir SELECT st alın

MTVF (Çoklu ifadeli TVF): Geliştirici, bir tablo değişkeni oluşturur ve yükler.

bir sorgu yapacaksanız, Satır İçi Tablo Değerli işlevinize aşağıdaki gibi katılabilirsiniz:

SELECT
    a.*,b.*
    FROM AAAA a
        INNER JOIN MyNS.GetUnshippedOrders() b ON a.z=b.z

biraz ek yüke neden olacak ve iyi çalışacaktır.

Değerli Çoklu Tablo Tablonuzu benzer bir sorguda kullanmaya çalışırsanız, performans sorunlarınız olacaktır:

SELECT
    x.a,x.b,x.c,(SELECT OrderQty FROM MyNS.GetLastShipped(x.CustomerID)) AS Qty
    FROM xxxx   x

işlevi, döndürülen her satır için 1 kez yürüteceğiniz için, sonuç kümesi büyüdükçe, daha yavaş ve daha yavaş çalışacaktır.