Dasar-dasar ekspresi tabel, Bagian 2 – Tabel turunan, pertimbangan logis

Definisi tabel turunan muncul di mana tabel dasar biasanya dapat muncul, di klausa FROM kueri luar. Ini bisa menjadi input ke operator tabel seperti JOIN, APPLY, PIVOT dan UNPIVOT. Saat digunakan sebagai input yang tepat untuk operator APPLY, bagian dari tabel turunan diizinkan untuk memiliki korelasi ke kolom dari tabel luar (lebih lanjut tentang ini di artikel mendatang khusus dalam seri ini). Jika tidak, ekspresi tabel harus mandiri.

Pernyataan luar dapat memiliki semua elemen kueri yang biasa. Dalam kasus pernyataan SELECT:WHERE, GROUP BY, HAVING, ORDER BY dan seperti yang disebutkan, operator tabel dalam klausa FROM.

Berikut ini contoh kueri sederhana terhadap tabel turunan yang mewakili pelanggan AS:

SELECT custid, companynameFROM ( SELECT custid, companyname FROM Sales.Customers WHERE country =N'USA' ) AS UC;

Kueri ini menghasilkan keluaran berikut:

nama perusahaan custid------- ---------------32 Pelanggan YSIQX36 Pelanggan LVJSO43 Pelanggan UISOJ45 Pelanggan QXPPT48 Pelanggan DVFMB55 Pelanggan KZQZT65 Pelanggan NYUHS71 Pelanggan LCOUJ75 Pelanggan XOJYP77 Pelanggan LCYBZ78 Pelanggan NLTYP82 Pelanggan EYHKM89 Pelanggan YBQTI

Ada tiga bagian utama yang harus diidentifikasi dalam pernyataan yang melibatkan definisi tabel turunan:

1. Ekspresi tabel (kueri dalam)
2. Nama tabel turunan, atau lebih tepatnya, apa yang dalam teori relasional dianggap sebagai variabel rentang
3. Pernyataan luar

Ekspresi tabel seharusnya mewakili tabel, dan dengan demikian, harus memenuhi persyaratan tertentu yang tidak harus dipenuhi oleh kueri normal. Saya akan memberikan detailnya segera di bagian “Ekspresi tabel adalah tabel”.

Adapun nama tabel turunan target; asumsi umum di antara pengembang T-SQL adalah bahwa itu hanyalah nama, atau alias yang Anda tetapkan ke tabel target. Demikian pula, pertimbangkan kueri berikut:

PILIH custid, companynameFROM Sales.Customers AS CWHERE country =N'USA';

Juga di sini, asumsi umum adalah bahwa AS C hanyalah cara untuk mengganti nama, atau alias, tabel Pelanggan untuk keperluan kueri ini, dimulai dengan langkah pemrosesan kueri logis di mana nama ditetapkan dan seterusnya. Namun, dari sudut pandang teori relasional, ada makna yang lebih dalam dari apa yang diwakili oleh C. C adalah apa yang dikenal sebagai variabel rentang. C adalah variabel relasi turunan yang berkisar di atas tupel dalam variabel relasi input Pelanggan. Dalam contoh di atas, rentang C di atas tupel di Pelanggan dan mengevaluasi negara predikat =N'USA'. Tupel yang predikatnya bernilai true menjadi bagian dari relasi hasil C.

Ekspresi tabel adalah tabel

Dengan latar belakang yang saya berikan sejauh ini, apa yang akan saya jelaskan selanjutnya seharusnya tidak mengejutkan. Bagian dari definisi tabel turunan adalah tabel . Itulah yang terjadi bahkan jika itu dinyatakan sebagai kueri. Ingat properti penutupan aljabar relasional? Hal yang sama berlaku untuk sisa dari ekspresi tabel bernama yang disebutkan di atas (CTE, tampilan, dan TVF sebaris). Seperti yang telah Anda pelajari, tabel SQL adalah padanan dari hubungan teori relasional , meskipun bukan pasangan yang sempurna. Dengan demikian, ekspresi tabel harus memenuhi persyaratan tertentu untuk memastikan bahwa hasilnya adalah tabel—yang tidak harus dimiliki oleh kueri yang tidak digunakan sebagai ekspresi tabel. Berikut adalah tiga persyaratan khusus:

• Semua kolom ekspresi tabel harus memiliki nama
• Semua nama kolom ekspresi tabel harus unik
• Baris ekspresi tabel tidak memiliki urutan

Mari kita uraikan persyaratan ini satu per satu, membahas relevansinya dengan teori relasional dan SQL.

Semua kolom harus memiliki nama

Ingatlah bahwa suatu relasi memiliki heading dan body. Judul relasi adalah sekumpulan atribut (kolom dalam SQL). Atribut memiliki nama dan nama tipe, dan diidentifikasi dengan namanya. Kueri yang tidak digunakan sebagai ekspresi tabel tidak harus menetapkan nama ke semua kolom target. Pertimbangkan kueri berikut sebagai contoh:

SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city)FROM HR.Employees;

Kueri ini menghasilkan keluaran berikut:

empid firstname lastname (Tanpa nama kolom)------ ---------- ---------- ------------- ----1 Sara Davis USA/WA/Seattle2 Don Funk USA/WA/Tacoma3 Judy Lew USA/WA/Kirkland4 Yael Peled USA/WA/Redmond5 Sven Mortensen UK/London6 Paul Suurs UK/London7 Russell King UK/London8 Maria Cameron AS/WA/Seattle9 Patricia Doyle Inggris/London

Keluaran kueri memiliki kolom anonim yang dihasilkan dari penggabungan atribut lokasi menggunakan fungsi CONCAT_WS. (Omong-omong, fungsi ini telah ditambahkan di SQL Server 2017, jadi jika Anda menjalankan kode di versi sebelumnya, silakan ganti komputasi ini dengan komputasi alternatif pilihan Anda.) Oleh karena itu, kueri ini tidak mengembalikan tabel, belum lagi relasi. Oleh karena itu, tidak valid untuk menggunakan kueri seperti ekspresi tabel/kueri bagian dalam dari definisi tabel turunan.

Cobalah:

SELECT *FROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) FROM HR.Employees ) AS D;

Anda mendapatkan kesalahan berikut:

Sebagai tambahan, perhatikan sesuatu yang menarik tentang pesan kesalahan? Itu mengeluh tentang kolom 4, menyoroti perbedaan antara kolom dalam SQL dan atribut dalam teori relasional.

Solusinya adalah, tentu saja, untuk memastikan bahwa Anda secara eksplisit menetapkan nama ke kolom yang dihasilkan dari perhitungan. T-SQL mendukung beberapa teknik penamaan kolom. Saya akan menyebutkan dua di antaranya.

Anda dapat menggunakan teknik penamaan sebaris di mana Anda menetapkan nama kolom target setelah perhitungan dan klausa AS opsional, seperti dalam < expression > [ AS ] < column name > , seperti ini:

SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) AS custlocation FROM HR.Employeees ) AS D;

Kueri ini menghasilkan keluaran berikut:

empid firstname lastname custlocation------ ---------- ---------- ----------------1 Sara Davis USA/WA/Seattle2 Don Funk USA/WA/Tacoma3 Judy Lew USA/WA/Kirkland4 Yael Peled USA/WA/Redmond5 Sven Mortensen UK/London6 Paul Suurs UK/London7 Russell King UK/London8 Maria Cameron USA/WA/Seattle9 Patricia Doyle Inggris/London

Dengan menggunakan teknik ini, sangat mudah saat meninjau kode untuk mengetahui nama kolom target yang ditetapkan ke ekspresi mana. Selain itu, Anda hanya perlu memberi nama kolom yang belum memiliki nama.

Anda juga dapat menggunakan teknik penamaan kolom yang lebih eksternal di mana Anda menentukan nama kolom target dalam tanda kurung tepat setelah nama tabel turunan, seperti:

SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) FROM HR.Employees ) AS D(empid, firstname, lastname, custlocation); 

 Dengan teknik ini, Anda harus membuat daftar nama untuk semua kolom—termasuk yang sudah memiliki nama. Penetapan nama kolom target dilakukan berdasarkan posisi, kiri ke kanan, yaitu, nama kolom target pertama mewakili ekspresi pertama dalam daftar SELECT kueri dalam; nama kolom target kedua mewakili ekspresi kedua; dan seterusnya. 
 

 Perhatikan bahwa dalam kasus inkonsistensi antara nama kolom dalam dan luar, katakanlah, karena bug dalam kode, cakupan nama dalam adalah kueri dalam—atau, lebih tepatnya, variabel rentang dalam (di sini secara implisit HR.Employees AS Karyawan)—dan ruang lingkup nama luar adalah variabel rentang luar (D dalam kasus kami). Ada sedikit lebih banyak yang terlibat dalam pelingkupan nama kolom yang berkaitan dengan pemrosesan kueri logis, tetapi itu adalah item untuk diskusi nanti.
 

 Potensi bug dengan sintaks penamaan eksternal paling baik dijelaskan dengan sebuah contoh. 
 

 Periksa output dari kueri sebelumnya, dengan set lengkap karyawan dari tabel HR.Employees. Kemudian, pertimbangkan kueri berikut, dan sebelum menjalankannya, coba cari tahu karyawan mana yang Anda harapkan akan dilihat dalam hasil:
 
SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid, firstname, lastname, CONCAT_WS(N'/', country, region, city) FROM HR.Employees WHERE lastname LIKE N'D%' ) AS D(empid, lastname, firstname, custlocation)WHERE firstname LIKE N'D%';
 

 Jika Anda mengharapkan kueri mengembalikan kumpulan kosong untuk data sampel yang diberikan, karena saat ini tidak ada karyawan dengan nama belakang dan nama depan yang dimulai dengan huruf D, Anda kehilangan bug dalam kode. 
 

 Sekarang jalankan kueri, dan periksa keluaran sebenarnya:
 
empid firstname lastname custlocation------ ---------- --------- ---------------1 Davis Sara AS/WA/Seattle9 Doyle Patricia Inggris/London
 

 Apa yang terjadi?
 

 Kueri dalam menentukan nama depan sebagai kolom kedua, dan nama belakang sebagai kolom ketiga dalam daftar SELECT. Kode yang menetapkan nama kolom target tabel turunan di kueri luar menentukan nama belakang kedua dan nama depan ketiga. Kode menamai nama depan sebagai nama belakang dan nama belakang sebagai nama depan dalam variabel rentang D. Secara efektif, Anda hanya memfilter karyawan yang nama belakangnya dimulai dengan huruf D. Anda tidak memfilter karyawan dengan nama belakang dan nama depan yang diawali dengan huruf D.
 

 Sintaks aliasing sebaris tidak rentan terhadap bug semacam itu. Pertama, Anda biasanya tidak membuat alias kolom yang sudah memiliki nama yang Anda sukai. Kedua, bahkan jika Anda ingin menetapkan alias yang berbeda untuk kolom yang sudah memiliki nama, kemungkinan besar dengan sintaks  AS  Anda akan menetapkan alias yang salah. Pikirkan tentang itu; seberapa besar kemungkinan Anda akan menulis seperti ini:
 
SELECT empid, firstname, lastname, custlocationFROM ( SELECT empid AS empid, firstname AS lastname, lastname AS firstname, CONCAT_WS(N'/', country, region, city) AS custlocation FROM HR.Employees WHERE lastname LIKE N'D %' ) SEBAGAI DWHERE firstname LIKE N'D%';
 

 Jelas, sangat tidak mungkin.
 
Semua nama kolom harus unik
 

 Kembali ke fakta bahwa heading suatu relasi adalah sekumpulan atribut, dan mengingat bahwa suatu atribut diidentifikasi dengan nama, nama atribut harus unik untuk relasi yang sama. Dalam kueri tertentu, Anda selalu dapat merujuk ke atribut menggunakan nama dua bagian dengan nama variabel rentang sebagai penentu, seperti dalam .. Jika nama kolom tanpa qualifier tidak ambigu, Anda dapat menghilangkan awalan nama variabel range. Yang penting untuk diingat adalah apa yang saya katakan sebelumnya tentang ruang lingkup nama kolom. Dalam kode yang melibatkan ekspresi tabel bernama, dengan kueri dalam (ekspresi tabel) dan kueri luar, cakupan nama kolom di kueri dalam adalah variabel rentang dalam, dan cakupan nama kolom di luar query adalah variabel jangkauan luar. Jika kueri dalam melibatkan beberapa tabel sumber dengan nama kolom yang sama, Anda masih dapat merujuk ke kolom tersebut dengan cara yang jelas dengan menambahkan nama variabel rentang sebagai awalan. Jika Anda tidak menetapkan nama variabel rentang secara eksplisit, Anda akan menetapkannya secara implisit, seolah-olah Anda menggunakan  AS .
 

 Pertimbangkan kueri mandiri berikut sebagai contoh:
 
PILIH C.custid, O.custid, O.orderidFROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid;
 

 Kueri ini tidak gagal dengan kesalahan nama kolom duplikat karena satu kolom custid sebenarnya bernama C.custid dan O.custid lainnya dalam lingkup kueri saat ini. Kueri ini menghasilkan keluaran berikut:
 
pesanan custid custid----------- ----------- -----------1 1 106431 1 106921 1 107021 1 108351 1 109521 1 110112 2 103082 2 106252 2 107592 2 10926...
 

 Namun, coba gunakan kueri ini sebagai ekspresi tabel dalam definisi tabel turunan bernama CO, seperti:
 
PILIH *FROM ( SELECT C.custid, O.custid, O.orderid FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) AS CO;
 

 Sejauh menyangkut kueri luar, Anda memiliki satu variabel rentang bernama CO, dan cakupan semua nama kolom di kueri luar adalah variabel rentang itu. Nama semua kolom dalam variabel rentang tertentu (ingat, variabel rentang adalah variabel relasi) harus unik. Karenanya, Anda mendapatkan kesalahan berikut:
 Msg 8156, Level 16, State 1, Line 80
Kolom 'custid' ditentukan beberapa kali untuk 'CO'. 

 Cara mengatasinya tentu saja dengan menetapkan nama kolom yang berbeda ke dua kolom custid sejauh menyangkut variabel rentang CO, seperti:
 
PILIH *FROM ( PILIH C.custid AS custcustid, O.custid AS ordercustid, O.orderid FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) AS CO; 

 Kueri ini menghasilkan keluaran berikut:
 
pesanan custidcustid orderid----------- ----------- -----------1 1 106431 1 106921 1 107021 1 108351 1 109521 1 110112 2 103082 2 106252 2 107592 2 10926...
 

 Jika Anda mengikuti praktik yang baik, Anda secara eksplisit mencantumkan nama kolom di daftar SELECT kueri terluar. Karena hanya ada satu variabel rentang yang terlibat, Anda tidak perlu menggunakan nama dua bagian untuk referensi kolom luar. Jika Anda ingin menggunakan nama dua bagian, Anda mengawali nama kolom dengan nama variabel rentang luar CO, seperti:
 
PILIH CO.custcustid, CO.ordercustid, CO.orderidFROM ( PILIH C.custid AS custcustid, O.custid AS ordercustid, O.orderid FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) SEBAGAI CO;
 
Tidak ada pesanan
 

 Ada cukup banyak yang harus saya katakan tentang ekspresi dan pengurutan tabel bernama — cukup untuk sebuah artikel sendiri — jadi saya akan mendedikasikan artikel mendatang untuk topik ini. Namun, saya ingin menyentuh topik ini secara singkat di sini karena ini sangat penting. Ingatlah bahwa tubuh suatu relasi adalah kumpulan tupel, dan demikian pula, tubuh tabel adalah kumpulan baris. Satu set tidak memiliki urutan. Namun, SQL mengizinkan kueri terluar untuk memiliki klausa ORDER BY yang menyajikan makna pengurutan presentasi, seperti yang ditunjukkan oleh kueri berikut:
 
PILIH orderid, valFROM Sales.OrderValuesORDER BY val DESC;
 

 Namun, yang perlu Anda pahami adalah bahwa kueri ini tidak mengembalikan relasi sebagai hasilnya. Bahkan dari perspektif SQL, kueri tidak mengembalikan tabel sebagai hasilnya, dan karenanya tidak dianggap sebagai ekspresi tabel. Akibatnya, tidak valid untuk menggunakan kueri seperti itu sebagai bagian ekspresi tabel dari definisi tabel turunan. 
 

 Coba jalankan kode berikut:
 
SELECT orderid, valFROM ( SELECT orderid, val FROM Sales.OrderValues ​​ORDER BY val DESC ) AS D;
 

 Anda mendapatkan kesalahan berikut:
 Msg 1033, Level 15, State 1, Line 124
Klausa ORDER BY tidak valid dalam tampilan, fungsi inline, tabel turunan, subkueri, dan ekspresi tabel umum, kecuali TOP, OFFSET atau FOR XML juga ditentukan. 

 Saya akan menangani kecuali bagian dari pesan kesalahan segera.
 

 Jika Anda ingin kueri terluar mengembalikan hasil yang diurutkan, Anda perlu menentukan klausa ORDER BY di kueri terluar, seperti:
 
SELECT orderid, valFROM ( SELECT orderid, val FROM Sales.OrderValues ​​) AS DORDER BY val DESC;
 

 Adapun kecuali bagian dari pesan kesalahan; T-SQL mendukung filter TOP berpemilik serta filter OFFSET-FETCH standar. Kedua filter mengandalkan klausa ORDER BY dalam cakupan kueri yang sama untuk menentukan baris teratas mana yang akan difilter. Sayangnya, ini adalah hasil jebakan dalam desain fitur ini, yang tidak memisahkan urutan presentasi dari urutan filter. Bagaimanapun, baik Microsoft dengan filter TOP-nya, dan standar dengan filter OFFSET-FETCH-nya, memungkinkan menentukan klausa ORDER BY dalam kueri dalam selama itu juga menentukan filter TOP atau OFFSET-FETCH, masing-masing. Jadi, kueri ini valid, misalnya:
 
SELECT orderid, valFROM ( SELECT TOP (3) orderid, val FROM Sales.OrderValues ​​ORDER BY val DESC ) AS D;
 

 Ketika saya menjalankan kueri ini di sistem saya, itu menghasilkan output berikut:
 
nilai pemesanan-------- ---------10865 16387.5010981 15810.0011030 12615.05
 

 Yang penting untuk ditekankan, adalah bahwa satu-satunya alasan klausa ORDER BY diperbolehkan dalam kueri dalam adalah untuk mendukung filter TOP. Itulah satu-satunya jaminan yang Anda dapatkan sejauh menyangkut pemesanan. Karena kueri luar juga tidak memiliki klausa ORDER BY, Anda tidak mendapatkan jaminan untuk pemesanan presentasi tertentu dari kueri ini, terlepas dari apa pun perilaku yang diamati. Itulah yang terjadi di T-SQL, dan juga dalam standar. Berikut kutipan dari standar yang menangani bagian ini:
 “Pengurutan baris tabel yang ditentukan oleh  dijamin hanya untuk  yang segera berisi .” 

 Seperti yang disebutkan, ada banyak lagi yang bisa dikatakan tentang ekspresi dan pengurutan tabel, yang akan saya lakukan di artikel mendatang. Saya juga akan memberikan contoh yang menunjukkan bagaimana kurangnya klausa ORDER BY di kueri luar berarti Anda tidak mendapatkan jaminan pemesanan presentasi.
 

 Jadi, ekspresi tabel, misalnya, kueri dalam dalam definisi tabel turunan, adalah tabel. Demikian pula, tabel turunan (dalam arti khusus) itu sendiri juga merupakan tabel. Ini bukan meja dasar, tetapi tetap saja meja. Hal yang sama berlaku untuk CTE, tampilan, dan TVF sebaris. Mereka bukan tabel dasar, melainkan tabel turunan (dalam pengertian yang lebih umum), tetapi bagaimanapun juga tabel.
 
Kekurangan desain
 

 Tabel turunan memiliki dua kekurangan utama dalam desainnya. Keduanya berkaitan dengan fakta bahwa tabel turunan didefinisikan dalam klausa FROM dari kueri luar.
 

 Satu cacat desain berkaitan dengan fakta bahwa jika Anda perlu membuat kueri tabel turunan dari kueri luar, dan pada gilirannya menggunakan kueri itu sebagai ekspresi tabel dalam definisi tabel turunan lain, Anda akhirnya membuat kueri tabel turunan tersebut. Dalam komputasi, penyatuan kode secara eksplisit yang melibatkan berbagai tingkat penyarangan cenderung menghasilkan kode kompleks yang sulit untuk dipelihara.
 

 Berikut adalah contoh yang sangat mendasar yang menunjukkan hal ini:
 
SELECT orderyear, numcustsFROM ( SELECT orderyear, COUNT(DISTINCT custid) AS numcusts FROM ( SELECT YEAR(orderdate) AS orderyear, custid FROM Sales.Orders ) AS D1 GROUP BY orderyear ) AS D2WHERE numcusts> 70;
 

 Kode ini mengembalikan tahun pemesanan dan jumlah pelanggan yang melakukan pemesanan selama setiap tahun, hanya untuk tahun di mana jumlah pelanggan yang melakukan pemesanan lebih besar dari 70.
 

 Motivasi utama menggunakan ekspresi tabel di sini adalah agar dapat merujuk ke kolom alias beberapa kali. Kueri terdalam yang digunakan sebagai ekspresi tabel untuk tabel turunan D1 mengkueri tabel Sales.Orders, dan menetapkan nama kolom orderyear ke ekspresi YEAR(orderdate), dan juga mengembalikan kolom custid. Kueri terhadap D1 mengelompokkan baris dari D1 menurut tahun pesanan, dan mengembalikan tahun pesanan serta jumlah pelanggan yang berbeda yang memesan selama tahun yang bersangkutan alias sebagai numcusts. Kode mendefinisikan tabel turunan yang disebut D2 berdasarkan kueri ini. Kueri terluar dari kueri D2 dan filter hanya tahun di mana jumlah pelanggan yang melakukan pemesanan lebih besar dari 70.
 

 Upaya untuk meninjau kode ini atau memecahkan masalah jika terjadi masalah sulit dilakukan karena beberapa tingkat penyarangan. Alih-alih meninjau kode dengan cara yang lebih alami dari atas ke bawah, Anda mendapati diri Anda harus menganalisisnya mulai dari unit terdalam dan secara bertahap keluar, karena itu lebih praktis.
 

 Inti dari penggunaan tabel turunan dalam contoh ini adalah untuk menyederhanakan kode dengan menghindari kebutuhan untuk mengulang ekspresi. Tapi saya tidak yakin bahwa solusi ini mencapai tujuan ini. Dalam hal ini, Anda mungkin lebih baik mengulangi beberapa ekspresi, menghindari kebutuhan untuk menggunakan tabel turunan sama sekali, seperti:
 
PILIH TAHUN(tanggal pemesanan) SEBAGAI tahun pesanan, COUNT(JUMLAH BERBEDA) SEBAGAI numcustsFROM Penjualan.OrdersGROUP BY YEAR(orderdate)HAVING COUNT(DISTINCT custid)> 70;
 

 Ingatlah bahwa saya menunjukkan contoh yang sangat sederhana di sini untuk tujuan ilustrasi. Bayangkan kode produksi dengan tingkat yang lebih tinggi, dan dengan kode yang lebih panjang dan rumit, dan Anda dapat melihat bagaimana pemeliharaannya menjadi jauh lebih rumit.
 

 Kelemahan lain dalam desain tabel turunan berkaitan dengan kasus di mana Anda perlu berinteraksi dengan beberapa instance dari tabel turunan yang sama. Pertimbangkan kueri berikut sebagai contoh:
 
SELECT CUR.orderyear, CUR.numorders, CUR.numorders - PRV.numorders AS diffFROM ( SELECT YEAR(orderdate) AS orderyear, COUNT(*) AS numorders FROM Sales.Orders GROUP BY YEAR(orderdate) ) AS CUR LEFT OUTER JOIN ( SELECT YEAR(orderdate) AS orderyear, COUNT(*) AS numorders FROM Sales.Orders GROUP BY YEAR(orderdate) ) AS PRV ON CUR.orderyear =PRV.orderyear + 1;
 

 Kode ini menghitung jumlah pesanan yang diproses di setiap tahun, serta perbedaan dari tahun sebelumnya. Abaikan fakta bahwa ada cara yang lebih sederhana untuk mencapai tugas yang sama dengan fungsi jendela—saya menggunakan kode ini untuk mengilustrasikan poin tertentu, jadi tugas itu sendiri dan berbagai cara untuk menyelesaikannya tidak signifikan. 
 

 Gabung adalah operator tabel yang memperlakukan dua inputnya sebagai satu set—artinya tidak ada urutan di antara keduanya. Mereka disebut sebagai input kiri dan kanan sehingga Anda dapat menandai salah satunya (atau keduanya) sebagai tabel yang diawetkan di gabungan luar, tetapi tetap saja, tidak ada yang pertama dan kedua di antara keduanya. Anda diperbolehkan menggunakan tabel turunan sebagai input gabungan, tetapi nama variabel rentang yang Anda tetapkan ke input kiri tidak dapat diakses dalam definisi input kanan. Itu karena keduanya secara konseptual didefinisikan dalam langkah logis yang sama, seolah-olah pada titik waktu yang sama. Akibatnya, saat menggabungkan tabel turunan, Anda tidak dapat mendefinisikan dua variabel rentang berdasarkan satu ekspresi tabel. Sayangnya, Anda harus mengulang kode, mendefinisikan dua variabel rentang berdasarkan dua salinan kode yang identik. Ini tentu saja memperumit pemeliharaan kode, dan meningkatkan kemungkinan bug. Setiap perubahan yang Anda buat pada satu ekspresi tabel juga perlu diterapkan ke yang lain.
 

 Seperti yang akan saya jelaskan di artikel mendatang, CTE, dalam desainnya, tidak menimbulkan dua kekurangan yang ditimbulkan oleh tabel turunan ini.
 
Konstruktor nilai tabel
 

 Konstruktor nilai tabel memungkinkan Anda membuat nilai tabel berdasarkan ekspresi skalar mandiri. Anda kemudian dapat menggunakan tabel seperti itu dalam kueri luar seperti Anda menggunakan tabel turunan yang didasarkan pada kueri dalam. Dalam artikel mendatang saya membahas tabel turunan lateral and correlations in detail, and I’ll show more sophisticated forms of table value constructors. In this article, though, I’ll focus on a simple form that is based purely on self-contained scalar expressions.
 

 The general syntax for a query against a table value constructor is as follows:
 SELECT 
FROM (  ) AS (); 

 The table value constructor is defined in the FROM clause of the outer query.

 The table’s body is made of a VALUES clause, followed by a comma separated list of pairs of parentheses, each defining a row with a comma separated list of expressions forming the row’s values.

 The table’s heading is a comma separated list of the target column names. I’ll talk about a shortcoming of this syntax regarding the table’s heading shortly.

 The following code uses a table value constructor to define a table called MyCusts with three columns called custid, companyname and contractdate, and three rows:
SELECT custid, companyname, contractdateFROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid, companyname, contractdate);

 The above code is equivalent (both logically and in performance terms) in T-SQL to the following alternative:
SELECT custid, companyname, contractdateFROM ( SELECT 2, 'Cust 2', '20200212' UNION ALL SELECT 3, 'Cust 3', '20200118' UNION ALL SELECT 5, 'Cust 5', '20200401' ) AS MyCusts(custid, companyname, contractdate);

 The two are internally algebrized the same way. The syntax with the VALUES clause is standard whereas the syntax with the unified FROMless queries isn’t, hence I prefer the former.

 There is a shortcoming in the design of table value constructors in both standard SQL and in T-SQL. Remember that the heading of a relation is made of a set of attributes, and an attribute has a name and a type name. In the table value constructor’s syntax, you specify the column names, but not their data types. Suppose that you need the custid column to be of a SMALLINT type, the companyname column of a VARCHAR(50) type, and the contractdate column of a DATE type. It would have been good if we were able to define the column types as part of the definition of the table’s heading, like so (this syntax isn’t supported):
SELECT custid, companyname, contractdateFROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid SMALLINT, companyname VARCHAR(50), contractdate DATE);

 That’s of course just wishful thinking.

 The way it works in T-SQL, is that each literal that is based on a constant has a predetermined type irrespective of context. For instance, can you guess what the types of the following literals are:
 
1
 
2147483647
 
2147483648
 
1E
 
'1E'
 
'20200212'
 

 Is 1 considered BIT, INT, SMALLINT, other?

 Is 1E considered VARBINARY(1), VARCHAR(2), other?

 Is '20200212' considered DATE, DATETIME, VARCHAR(8), CHAR(8), other?

 There’s a simple trick to figure out the default type of a literal, using the SQL_VARIANT_PROPERTY function with the 'BaseType' property, like so:
SELECT SQL_VARIANT_PROPERTY(2147483648, 'BaseType');

 What happens is that SQL Server implicitly converts the literal to SQL_VARIANT—since that’s what the function expects—but preserves its base type. It then reports the base type as requested.

 Similarly, you can query other properties of the input value, like the maximum length (MaxLength), Precision, Scale, and so on.

 Try it with the aforementioned literal values, and you will get the following:
 
1:INT 
2147483647:INT 
2147483648:NUMERIC(10, 0) 
1E:FLOAT 
'1E':VARCHAR(2) 
'20200212':VARCHAR(8)

 As you can see, SQL Server has default assumptions about the data type, maximum length, precision, scale, and so on.

 There are some cases where you need to specify a literal of a certain type, but you cannot do it directly in T-SQL. For example, you cannot specify a literal of the following types directly:BIT, TINYINT, BIGINT, all date and time types, and quite a few others. Unfortunately, T-SQL doesn’t provide a selector property for its types, which would have served exactly the needed purpose of selecting a value of the given type. Of course, you can always convert an expression’s type explicitly using the CAST or CONVERT function, as in CAST(5 AS SMALLINT). If you don’t, SQL Server will sometimes need to implicitly convert some of your expressions to a different type based on its implicit conversion rules. For example, when you try to compare values of different types, e.g., WHERE datecol ='20200212', assuming datecol is of a DATE type. Another example is when you specify a literal in an INSERT or an UPDATE statement, and the literal’s type is different than the target column’s type.

 If all this is not confusing enough, set operators like UNION ALL rely on data type precedence to define the target column types—and remember, a table value constructor is algebrized like a series of UNION ALL operations. Consider the table value constructor shown earlier:
SELECT custid, companyname, contractdateFROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid, companyname, contractdate);

 Each literal here has a predetermined type. 2, 3 and 5 are all of an INT type, so clearly the custid target column type is INT. If you had the values 1000000000, 3000000000 and 2000000000, the first and the third are considered INT and the second is considered NUMERIC(10, 0). According to data type precedence NUMERIC (same as DECIMAL) is stronger than INT, hence in such a case the target column type would be NUMERIC(10, 0).

 If you want to figure out which data types SQL Server chooses for the target columns in your table value constructor, you have a few options. One is to use a SELECT INTO statement to write the table value constructor’s data into a temporary table, and then query the metadata for the temporary table, like so:
SELECT custid, companyname, contractdateINTO #MyCustsFROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid, companyname, contractdate); SELECT name AS colname, TYPE_NAME(system_type_id) AS typename, max_length AS maxlengthFROM tempdb.sys.columnsWHERE OBJECT_ID =OBJECT_ID(N'tempdb..#MyCusts');

 Here’s the output of this code:
colname typename maxlength------------- ---------- ---------custid int 4companyname varchar 6contractdate varchar 8

 You can then drop the temporary table for cleanup:
DROP TABLE IF EXISTS #MyCusts;

 Another option is to use the SQL_VARIANT_PROPERTY, which I mentioned earlier, like so:
SELECT TOP (1) SQL_VARIANT_PROPERTY(custid, 'BaseType') AS custid_typename, SQL_VARIANT_PROPERTY(custid, 'MaxLength') AS custid_maxlength, SQL_VARIANT_PROPERTY(companyname, 'BaseType') AS companyname_typename, SQL_VARIANT_PROPERTY(companyname, 'MaxLength') AS companyname_maxlength, SQL_VARIANT_PROPERTY(contractdate, 'BaseType') AS contractdate_typename, SQL_VARIANT_PROPERTY(contractdate, 'MaxLength') AS contractdate_maxlengthFROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid, companyname, contractdate);

 This code generates the following output (formatted for readability):
custid_typename custid_maxlength-------------------- ---------------- int 4 companyname_typename companyname_maxlength -------------------- --------------------- varchar 6 contractdate_typename contractdate_maxlength--------------------- ----------------------varchar 8

 So, what if you need to control the types of the target columns? As mentioned earlier, say you need custid to be SMALLINT, companyname VARCHAR(50), and contractdate DATE.

 Don’t be misled to think that it’s enough to explicitly convert just one row’s values. If a corresponding value’s type in any other row is considered stronger, it would dictate the target column’s type. Here’s an example demonstrating this:
SELECT custid, companyname, contractdateINTO #MyCusts1FROM ( VALUES( CAST(2 AS SMALLINT), CAST('Cust 2' AS VARCHAR(50)), CAST('20200212' AS DATE)), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid, companyname, contractdate); SELECT name AS colname, TYPE_NAME(system_type_id) AS typename, max_length AS maxlengthFROM tempdb.sys.columnsWHERE OBJECT_ID =OBJECT_ID(N'tempdb..#MyCusts1');

 Kode ini menghasilkan output berikut:
colname typename maxlength------------- --------- ---------custid int 4companyname varchar 50contractdate date 3

 Notice that the type for custid is INT.

 The same applies never mind which row’s values you explicitly convert, if you don’t convert all of them. For example, here the code explicitly converts the types of the values in the second row:
SELECT custid, companyname, contractdateINTO #MyCusts2FROM ( VALUES( 2, 'Cust 2', '20200212'), ( CAST(3 AS SMALLINT), CAST('Cust 3' AS VARCHAR(50)), CAST('20200118' AS DATE) ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid, companyname, contractdate); SELECT name AS colname, TYPE_NAME(system_type_id) AS typename, max_length AS maxlengthFROM tempdb.sys.columnsWHERE OBJECT_ID =OBJECT_ID(N'tempdb..#MyCusts2');

 Kode ini menghasilkan output berikut:
colname typename maxlength------------- --------- ---------custid int 4companyname varchar 50contractdate date 3

 As you can see, custid is still of an INT type.

 You basically have two main options. One is to explicitly convert all values, like so:
SELECT custid, companyname, contractdateINTO #MyCusts3FROM ( VALUES( CAST(2 AS SMALLINT), CAST('Cust 2' AS VARCHAR(50)), CAST('20200212' AS DATE)), ( CAST(3 AS SMALLINT), CAST('Cust 3' AS VARCHAR(50)), CAST('20200118' AS DATE)), ( CAST(5 AS SMALLINT), CAST('Cust 5' AS VARCHAR(50)), CAST('20200401' AS DATE)) ) AS MyCusts(custid, companyname, contractdate); SELECT name AS colname, TYPE_NAME(system_type_id) AS typename, max_length AS maxlengthFROM tempdb.sys.columnsWHERE OBJECT_ID =OBJECT_ID(N'tempdb..#MyCusts3');

 This code generates the following output, showing all target columns have the desired types:
colname typename maxlength------------- --------- ---------custid smallint 2companyname varchar 50contractdate date 3

 That’s a lot of coding, though. Another option is to apply the conversions in the SELECT list of the query against the table value constructor, and then define a derived table against the query that applies the conversions, like so:
SELECT custid, companyname, contractdateINTO #MyCusts4FROM ( SELECT CAST(custid AS SMALLINT) AS custid, CAST(companyname AS VARCHAR(50)) AS companyname, CAST(contractdate AS DATE) AS contractdate FROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS D(custid, companyname, contractdate) ) AS MyCusts; SELECT name AS colname, TYPE_NAME(system_type_id) AS typename, max_length AS maxlengthFROM tempdb.sys.columnsWHERE OBJECT_ID =OBJECT_ID(N'tempdb..#MyCusts4');

 Kode ini menghasilkan output berikut:
colname typename maxlength------------- --------- ---------custid smallint 2companyname varchar 50contractdate date 3

 The reasoning for using the additional derived table is due to how logical query processing is designed. The SELECT clause is evaluated after FROM, WHERE, GROUP BY and HAVING. By applying the conversions in the SELECT list of the inner query, you allow expressions in all clauses of the outermost query to interact with the columns with the proper types.

 Back to our wishful thinking, clearly, it would be good if we ever get a syntax that allows explicit control of the types in the definition of the table value constructor’s heading, like so:
SELECT custid, companyname, contractdateFROM ( VALUES( 2, 'Cust 2', '20200212' ), ( 3, 'Cust 3', '20200118' ), ( 5, 'Cust 5', '20200401' ) ) AS MyCusts(custid SMALLINT, companyname VARCHAR(50), contractdate DATE);

 When you’re done, run the following code for cleanup:
DROP TABLE IF EXISTS #MyCusts1, #MyCusts2, #MyCusts3, #MyCusts4;
Used in modification statements

 T-SQL allows you to modify data through table expressions. That’s true for derived tables, CTEs, views and inline TVFs. What gets modified in practice is some underlying base table that is used by the table expression. I have much to say about modifying data through table expressions, and I will in a future article dedicated to this topic. Here, I just wanted to briefly mention the types of modification statements that specifically support derived tables, and provide the syntax.

 Derived tables can be used as the target table in DELETE and UPDATE statements, and also as the source table in the MERGE statement (in the USING clause). They cannot be used in the TRUNCATE statement, and as the target in the INSERT and MERGE statements.

 For the DELETE and UPDATE statements, the syntax for defining the derived table is a bit awkward. You don’t define the derived table in the DELETE and UPDATE clauses, like you would expect, but rather in a separate FROM clause. You then specify the derived table name in the DELETE or UPDATE clause.

 Here’s the general syntax of a DELETE statement against a derived table:
 DELETE [ FROM ] 
FROM (  ) [ AS ] [ () ]
[ WHERE  ]; 

 As an example (don’t actually run it), the following code deletes all US customers with a customer ID that is greater than the minimum for the same region (the region column represents the state for US customers):
 
DELETE FROM UCFROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY region ORDER BY custid) AS rownum FROM Sales.Customers WHERE country =N'USA' ) AS UCWHERE rownum> 1;
 

 Here’s the general syntax of an UPDATE statement against a derived table:
 UPDATE 
 SET 
FROM (  ) [ AS ] [ () ]
[ WHERE  ]; 

 As you can see, from the perspective of the definition of the derived table, it’s quite similar to the syntax of the DELETE statement. 
 

 As an example, the following code changes the company names of US customers to one using the format N'USA Cust ' + rownum, where rownum represents a position based on customer ID ordering:
 
BEGIN TRAN; UPDATE UC SET companyname =newcompanyname OUTPUT inserted.custid, deleted.companyname AS oldcompanyname, inserted.companyname AS newcompanynameFROM ( SELECT custid, companyname, N'USA Cust ' + CAST(ROW_NUMBER() OVER(ORDER BY custid) AS NVARCHAR(10)) AS newcompanyname FROM Sales.Customers WHERE country =N'USA' ) AS UC; ROLLBACK TRAN;
 

 The code applies the update in a transaction that it then rolls back so that the change won't stick.
 

 This code generates the following output, showing both the old and the new company names:
 
custid oldcompanyname newcompanyname------- --------------- ----------------32 Customer YSIQX USA Cust 136 Customer LVJSO USA Cust 243 Customer UISOJ USA Cust 345 Customer QXPPT USA Cust 448 Customer DVFMB USA Cust 555 Customer KZQZT USA Cust 665 Customer NYUHS USA Cust 771 Customer LCOUJ USA Cust 875 Customer XOJYP USA Cust 977 Customer LCYBZ USA Cust 1078 Customer NLTYP USA Cust 1182 Customer EYHKM USA Cust 1289 Customer YBQTI USA Cust 13
 

 That’s it for now on the topic. 
 
Ringkasan
 

 Derived tables are one of the four main types of named table expressions that T-SQL supports. In this article I focused on the logical aspects of derived tables. I described the syntax for defining them and their scope. 
 

 Remember that a table expression is a table and as such, all of its columns must have names, all column names must be unique, and the table has no order.
 

 The design of derived tables incurs two main flaws. In order to query one derived table from another, you need to nest your code, causing it to be more complex to maintain and troubleshoot. If you need to interact with multiple occurrences of the same table expression, using derived tables you are forced to duplicate your code, which hurts the maintainability of your solution.
 

 You can use a table value constructor to define a table based on self-contained expressions as opposed to querying some existing base tables.
 

 You can use derived tables in modification statements like DELETE and UPDATE, though the syntax for doing so is a bit awkward.
 

                
            

            

                
            
            

                

                    
                    Dasar-dasar ekspresi tabel, Bagian 3 – Tabel turunan, pertimbangan pengoptimalan          
                
                

                    Memvisualisasikan Tipping Point dengan Plan Explorer     
                    
                
             


             
                 
             
             





             

        

        


        

    




    


        
 

            

               
Database
  
Mysql
  
Oracle
  
Sqlserver
  
PostgreSQL
  
Access
  
SQLite
  
MariaDB
             

        

        

            


	 

                    
                    
                        
Solusi tantangan generator seri angka – Bagian 2 
                    
                
 

                    
                    
                        
Memulai Shareplex di Windows di AWS, Bagian 2 
                    
                
 

                    
                    
                        
Kunci Utama Dalam SQL:Semua yang Perlu Anda Ketahui Tentang Operasi Kunci Utama 
                    
                
 

                    
                    
                        
Bug T-SQL, perangkap, dan praktik terbaik – bergabung 
                    
                
 

                    
                    
                        
Kursor Ref Kuat Dengan Tipe Data Rekaman Berbasis Tabel 
                    
                
               
              



            
        




    

    
    

        
              
	

            

                

                    

                        
                    
                    
                        

                           Mengunggah gambar di CKEditor tanpa menggunakan plugin                         
                    
                
            
        

            

                

                    

                        
                    
                    
                        

                           Membangun Database yang Sangat Tersedia untuk Moodle Menggunakan PostgreSQL                         
                    
                
            
        

            

                

                    

                        
                    
                    
                        

                           Pemecahan Masalah AlwaysOn – Terkadang dibutuhkan banyak mata                         
                    
                
            
        

            

                

                    

                        
                    
                    
                        

                           Cara Memantau ProxySQL Anda dengan Prometheus dan ClusterControl