Neden SQL Daha Refactora Edilemez? [kapalı]

Herkes yeni geliştiricilerin uzun fonksiyonlar yazdığını bilir. İlerledikçe, kodunuzu daha küçük parçalara ayırma konusunda daha iyi olursunuz ve deneyim size bunun değerini gösterir.

SQL giriniz. Evet, kod hakkında SQL düşünme biçimi, kod hakkında düşünme yönteminden farklıdır, ancak bu ilke aynı şekilde uygulanabilir.

Diyelim ki formu alan bir sorgu var:

select * from subQuery1 inner join subQuerry2 left join subquerry3 left join join subQuery4 

Bazı kimlikleri veya tarihleri ​​kullanma vb.

Bu alt sorgular kendileri karmaşıktır ve kendi alt sorgularını içerebilir. Başka hiçbir programlama bağlamında, 1-4 arasındaki karmaşık alt sorgular için olan mantığın, hepsini birleştiren üst sorguma uygun olduğunu düşünmüyorum. O kadar basit görünüyor ki, bu alt sorguların prosedür kodu yazıyor olsaydım aynı fonksiyonlar gibi görünümler olarak tanımlanması gerekiyordu.

Peki neden bu yaygın uygulama değil? İnsanlar neden bu kadar uzun yekpare SQL sorguları yazıyorlar? SQL, neden prosedürel programlama gibi kapsamlı görünüm kullanımını desteklemiyor, kapsamlı işlev kullanımını teşvik ediyor. (Birçok işletme ortamında, görünüm oluşturmak, kolayca yapılan bir şey bile değildir. Talepler ve onaylar gerekir. Diğer programcı türlerinin, her işlev oluşturduklarında istek göndermesi gerekip gerekmediğini düşünün!)

Üç olası cevap düşündüm:

1. Bu zaten yaygın ve deneyimsiz insanlarla çalışıyorum

2. Tecrübeli programcılar karmaşık SQL yazmazlar çünkü zor veri işleme problemlerini prosedür koduyla çözmeyi tercih ederler

3. Başka bir şey

Bence asıl sorun, tüm veritabanlarının Ortak Tablo İfadelerini desteklememesidir.

İşverenim birçok şey için DB / 2 kullanıyor. Bunun en son sürümleri CTE'leri desteklemektedir, öyle ki ben böyle şeyleri yapabiliyorum:

with custs as (
    select acct# as accountNumber, cfname as firstName, clname as lastName,
    from wrdCsts
    where -- various criteria
)
, accounts as (
    select acct# as accountNumber, crBal as currentBalance
    from crzyAcctTbl
)
select firstName, lastName, currentBalance
from custs
inner join accounts on custs.accountNumber = accounts.accountNumber

Sonuç olarak, tablo / alan adlarını çok kısaltabiliriz ve esasen daha sonra kullanabileceğim daha okunaklı adlara sahip geçici görünümler oluşturuyorum. Tabii ki, sorgu uzar. Ancak sonuç, açıkça açıkça ayrılan bir şey yazabildiğimdir (CTE'leri DRY'yi almak için işlevleri kullandığınız şekilde) ve oldukça okunaklı bir kodla bitirdim. Ve alt sorgularımı kırabildiğim ve bir alt sorguya başka bir referans gönderebildiğim için hepsi "satır içi" değil. Bazen bir CTE yazdım, sonra dört referanslı CTE'nin hepsine referansta bulundum, sonra ana sorgu sendikasının bu son dört sonucun sonuçlarını aldım.

Bu yapılabilir:

• DB / 2
• PostGreSQL
• torpil
• MS SQL Sunucusu
• MySQL (en son sürüm; yine de yeni)
• muhtemelen diğerleri

Ancak, kodu daha temiz, daha okunaklı, daha kuru hale getirmek için UZUN bir yol kat ediyor.

Çeşitli sorulara ekleyebileceğim, yeni sorgumda uçmaya başladığım "standart bir kütüphane" geliştirdim. Bazıları da benim organizasyonumdaki diğer devler tarafından benimsendi.

Zamanla, bunlardan bazılarını görünümlere dönüştürmek mantıklı olabilir, öyle ki, bu "standart kütüphane" kopyalamak / yapıştırmak zorunda kalmadan kullanılabilir. Ancak CTE'lerim, tek bir CTE'ye sahip olamadığım çeşitli ihtiyaçlar için, biraz modsuz, bir görünüm oluşturmaya değecek kadar YÜKSEK olarak kullanamadığım çeşitli ihtiyaçlar için ince ayar yapıldı.

Görünüşe göre suçunun bir kısmı "neden CTE'leri bilmiyorum?" veya "neden DB'm CTE'leri desteklemiyor?"

Güncellemelere gelince ... evet, CTE'leri kullanabilirsiniz, ancak benim deneyimlerime göre, bunları set cümlesi içinde ve where cümlesi içinde kullanmak zorundasınız. Bütün güncelleme ifadesinden bir veya daha fazlasını tanımlayabilir ve ardından set / where cümlelerinde "ana sorgu" kısımlarına sahip olmanız iyi olur, ancak bu şekilde çalışmaz. Ayrıca, güncellemekte olduğunuz tablodaki belirsiz tablo / alan adlarından kaçının.

Silmek için CTE'leri kullanabilirsiniz. Bu tablodan silmek istediğiniz kayıtların PK / FK değerlerini belirlemek birden fazla CTE alabilir. Yine, değiştirdiğiniz tablodaki belirsiz tablo / alan adlarını önleyemezsiniz.

Eklentiyi seçmek için yapabileceğiniz gibi insomuch, kesici uçlar için CTE'leri kullanabilirsiniz. Her zaman olduğu gibi, değiştirdiğiniz tablodaki karanlık tablo / alan adlarıyla ilgileniyor olabilirsiniz.

SQL, tabloları, alıcıları / ayarlayıcıları içeren bir tablo nesnesinin eşdeğerini oluşturmanıza izin vermiyor. Bunun için, daha yordamsal / OO programlama dili ile birlikte bir tür ORM kullanmanız gerekecektir. Java / Hibernate'de bu tür şeyler yazdım.

Veri tabanı görünümlerinin oluşturulmasını engellemek çoğu zaman veri bankasındaki performans sorunlarının paranoyak olduğu kuruluşlar tarafından yapılır. Bu, SQL ile teknik bir mesele değil, bir organizasyon kültürü meselesidir.

Bunun ötesinde, büyük yekpare SQL sorguları birçok kez yazılmıştır, çünkü kullanım durumu çok belirgindir, çünkü SQL kodunun çok az bir kısmı diğer sorgularda gerçekten yeniden kullanılabilir. Karmaşık bir sorgu gerekiyorsa, genellikle çok farklı bir kullanım durumu içindir. SQL'i başka bir sorgudan kopyalamak genellikle bir başlangıç ​​noktasıdır, ancak yeni sorgudaki diğer alt sorgular ve JOIN'ler nedeniyle, kopyalanan SQL'i başka bir dilde "işlev" in yapacağı herhangi bir soyutlamayı kırmaya yetecek kadar değiştirmeye başladınız. için kullanılabilir. Bu da beni SQL'in refactor için zor olmasının en önemli nedenine getiriyor.

SQL, soyut davranışlarla (ya da kelimenin tam anlamıyla bir soyutlamasından değil) yalnızca somut veri yapılarıyla ilgilenir. SQL somut fikirler etrafında yazıldığından, tekrar kullanılabilir bir modüle soyutlayacak bir şey yoktur. Veritabanı görünümleri bu konuda yardımcı olabilir, ancak başka bir dilde "işlev" ile aynı düzeyde değildir. Veritabanı görünümü, sorgu olduğu kadar soyutlama değildir. Aslında bir veritabanı görünümü olan bir sorgu. Temelde bir tablo gibi kullanılır, ancak bir alt sorgu gibi yürütülür, bu yüzden tekrar, soyut değil, somut bir şeyle uğraşıyorsunuz.

Kod, yeniden kırmak için kolaylaşan soyutlamalar ile yapılır, çünkü bir soyutlama, bu soyutlamanın tüketicisinden uygulama ayrıntılarını gizler. Düz SQL böyle bir ayrım yapmaz, ancak SQL için PL / SQL gibi SQL veya SQL Server için Transact-SQL gibi prosedürel uzantılar satırları biraz bulanıklaştırmaya başlar.

Sorunuzdan / bakış açınızdan eksik olabileceğini düşündüğüm şey, SQL'in kümelerde işlemleri (küme işlemleri vb. Kullanarak) yürütmesidir.

Bu seviyede çalışırken, doğal olarak motor üzerinde belirli bir kontrolü bırakmanız gerekir. İmleçler kullanarak bazı yordamsal stil kodlarını hala zorlayabilirsiniz, ancak deneyim 99/100 kez gösterdiği gibi yapmamalısınız.

SQL'e yeniden düzenleme yapmak mümkündür ancak uygulama düzeyinde kodda alıştığımız gibi aynı kod yenileme ilkelerini kullanmaz. Bunun yerine, SQL motorunun kendisini nasıl kullanacağınızı optimize edersiniz.

Bu, çeşitli şekillerde yapılabilir. Microsoft SQL Server kullanıyorsanız, yaklaşık bir yürütme planı sağlamak için SSMS'yi kullanabilir ve kodunuzu ayarlamak için hangi adımları uygulayabileceğinizi görmek için bunu kullanabilirsiniz.

Kodun daha küçük modüllere bölünmesi durumunda, @ greg-burghardt'ın da belirttiği gibi, SQL genellikle amaç amaçlı bir kod parçasıdır ve sonuç olarak. Yapmanız gereken bir şey var, başka bir şey yok. SOLID'deki S'ye bağlı kalması, değiştirilmesinin / etkilenmesinin tek bir nedeni var ve o zaman bu sorgunun başka bir şey yapması için ihtiyacınız var. Kısaltmanın geri kalanı (OLID) burada geçerli değildir (AFAIK, bağımlılık enjeksiyonu, arayüzler veya SQL gibi bağımlılıklar yoktur) kullandığınız SQL'in lezzetine bağlı olarak, belirli sorguları sararak uzatabilirsiniz Bir saklı yordam / tablo işlevinde veya bunları alt sorgular olarak kullanarak, açık-kapalı ilkenin bir şekilde geçerli olacağını söyleyebilirim. Ama ben dalıyorum.

SQL kodunu nasıl görüntüleyeceğiniz konusunda paradigmanızı kaydırmanız gerektiğini düşünüyorum. Setin doğası gereği, uygulama seviyesindeki dillerin (jenerikler vb.) Sağlayabileceği birçok özelliği sağlayamaz. SQL asla böyle bir şey için tasarlanmamıştır, veri kümelerini sorgulamak için bir dildir ve her küme kendi kendine özgüdür.

Bununla birlikte, okunabilirliğin kurum içinde yüksek bir öncelik olması durumunda, kodunuzu daha iyi gösterebilmenin yolları vardır. Sık kullanılan SQL bloklarını (kullandığınız ortak veri kümeleri) bitlerini saklı yordamlara / tablo değeri işlevlerine kaydetmek ve bunları geçici tablolarda / tablo değişkenlerinde sorgulamak ve saklamak, ardından parçaları bir büyük işleme birleştirmek için bunları kullanmak aksi takdirde yazacağın bir seçenek. IMHO, SQL ile böyle bir şey yapmaya değmez.

Bir dil olarak programcılar tarafından bile olsa herkes tarafından kolayca okunabilir ve anlaşılabilir olacak şekilde tasarlanmıştır. Dolayısıyla, çok akıllıca bir şey yapmazsanız, SQL kodunu daha küçük byte boyutunda parçalara ayırmaya gerek yoktur. Kişisel olarak, bir veri ambarı ETL / Raporlama çözümü üzerinde çalışırken büyük SQL sorguları yazdım ve neler olduğu konusunda her şey hala çok netti. Başkasına biraz garip gelebilecek herhangi bir şey, kısa bir açıklama sağlamak için onunla birlikte kısa bir yorum seti alacaktır.

Umarım bu yardımcı olur.

Örnekteki "alt sorgular" üzerine odaklanacağım.

Neden bu kadar sık ​​kullanılıyor? Çünkü bir insanın doğal düşünme biçimini kullanıyorlar: Bu veri kümesine sahibim ve bunun bir alt kümesinde bir eylem yapmak ve buna başka bir veri alt kümesine katılmak istiyorum. Bir alt sorgu gördüğüm 10 üzerinden 9, yanlış kullanılmış. Alt sorgular hakkında çalışan şakam şudur: Katılmaktan korkan insanlar alt sorgular kullanırlar.

Bu tür alt sorguları görürseniz, genellikle en uygun olmayan veritabanı tasarımının da bir işaretidir.

Veritabanınız ne kadar normalize edilirse, ne kadar çok bağlanırsa, veri tabanınız o kadar büyük bir excel-tabakaya benziyorsa o kadar fazla alt seçim yapar.

SQL'de yeniden düzenleme yapmak genellikle farklı bir hedefe yöneliktir: "tablo taramalarından kaçınarak" daha fazla performans, daha iyi sorgu süreleri elde edin. Bunlar kodu daha az okunabilir hale getirebilir ancak çok değerlidir.

Öyleyse neden bu kadar büyük monolitik yeniden yapılandırılmamış sorgu görüyorsunuz?

• SQL, birçok yönden bir programlama dili değildir.
• Kötü veritabanı tasarımı.
• SQL'de akıcı olmayan insanlar.
• Veri tabanı üzerinde güç yok (örneğin, görünümleri kullanmasına izin verilmiyor)
• Refactoring ile farklı hedefler.

(benim için, SQL ile ne kadar deneyime sahip olursam, sorgularım o kadar az büyür, SQL her beceri seviyesindeki insanın işini ne olursa olsun işlerini yapmaları için de yapabilir.)

Görevlerin ayrılığı

SQL ruhunda, veritabanı şirketin verilerini içeren paylaşılan bir varlıktır ve korunmasının hayati önemi vardır. DBA'ya tapınağın koruyucusu olarak girer.

Veritabanında yeni bir görünüm oluşturmanın, kalıcı bir amaca hizmet ettiği ve bir kullanıcı topluluğu tarafından paylaşıldığı anlaşılmaktadır. DBA görünümünde, bu yalnızca görünümün verinin yapısı tarafından doğrulanması durumunda kabul edilebilir. Bir görünümdeki her değişiklik daha sonra uygulamayı kullanan, ancak görünümü keşfetmiş olanlar dahil tüm kullanıcıları için risklerle ilişkilendirilir. Son olarak, yeni nesnelerin yaratılması, yönetmeliklerin ve görüşme durumunda, temeldeki tabloların yetkilendirmeleri ile tutarlı bir şekilde yönetilmesini gerektirir.

Bütün bunlar, DBA'ların neden sadece bireysel uygulamaların kodları için görünümler eklemekten hoşlanmadıklarını açıklamaktadır.

SQL tasarımı

Güzel karmaşık sorgunuzdan birini ayrıştırırsanız, alt sorguların genellikle başka bir alt sorguya bağlı bir parametreye ihtiyacı olacağını öğrenebilirsiniz.

Bu nedenle, alt sorguları görünüşte dönüştürmek mutlaka belirtildiği kadar basit değildir. Değişken parametreleri yalıtmanız ve görünümünüzü, görünümde seçim kriteri olarak eklenebilecek şekilde tasarlamanız gerekir.

Ne yazık ki, bunu yaparken, bazen özel bir sorguda olduğundan daha fazla verilere ve daha az etkili bir şekilde erişmeyi empoze edebilirsiniz.

Özel uzantılar

PL / SQL veya T-SQL gibi SQL'in prosedürel uzantılarına bazı sorumluluklar aktararak, bazı refactoring'leri umabilirsiniz. Ancak, bunlar satıcıya bağımlıdır ve teknolojik bir bağımlılık yaratır. Ek olarak, bu uzantılar veritabanı sunucusunda çalıştırılarak, bir uygulama sunucusundan ölçeklendirilmesi daha zor olan bir kaynakta daha fazla işlem yükü oluşturur.

Ama sonuçta sorun ne?

Son olarak, görev ayrılığı ve SQL tasarımı, gücü ve sınırlamaları ile gerçek bir sorun mu? Sonunda, bu veritabanlarının kritik görev ortamları dahil olmak üzere çok kritik verileri başarıyla ve güvenilir bir şekilde ele aldığını kanıtladı.

Bu yüzden başarılı bir yeniden düzenlemeye ulaşmak için:

• daha iyi bir iletişim düşünün . DBA’nızın kısıtlarını anlamaya çalışın. Bir DBA'ya, veri yapıları tarafından yeni bir görüşün gerekçelendirildiğini, atılan bir geçici çözüm olmadığını ve güvenlik etkisi olmadığını kanıtlarsanız, kesinlikle oluşturulmasına izin vermeyi kabul edecektir. Çünkü, o zaman ortak bir ilgi olacaktır.

• önce kendi evinizi temizleyin : Hiçbir şey sizi birçok yerde SQL üretmeye zorlamaz. Uygulama kodunuzu yeniden düzenleyin, SQL erişimlerini izole etmek ve sık kullanılırsa yeniden kullanılabilir alt sorgular sağlamak için sınıflar veya işlevler oluşturun.

• iyileştirmek takım bilinci : Emin Başvurunuz DBMS motoru daha verimli yapılabildi görevleri performans göstermediğini olun. Doğru bir şekilde belirttiğiniz gibi, prosedürel yaklaşım ve veri odaklı yaklaşım, ekibin farklı üyeleri tarafından eşit şekilde yönetilmez. Arka planlarına bağlı. Ancak sistemi bir bütün olarak optimize etmek için ekibinizin bir bütün olarak anlaması gerekir. Bu yüzden farkındalık yaratın, böylece daha az deneyimli oyuncuların tekerleği yeniden icat etmediğinden ve DB düşüncelerini daha deneyimli üyelerle paylaşmadığından emin olmak için.

Re 1 ve 3 puan: Görüşler tek yol değildir. Geçici tablolar, martlar, tablo değişkenleri, toplu sütunlar, CTE'ler, fonksiyonlar, saklı prosedürler ve RDBMS'ye bağlı olarak muhtemelen diğer yapılar da vardır.

DBA'lar (ve ben hem DBA hem de geliştirici olan biri olarak konuşuyorum) dünyayı oldukça ikili bir şekilde görme eğilimindedirler, bu nedenle algılanan performans cezası nedeniyle genellikle görüş ve işlevler gibi şeylere karşı çıkarlar.

Son zamanlarda, karmaşık birleşmelere duyulan ihtiyaç, NF bakış açısına göre alt-optimal olmasına rağmen denormalize edilmiş masaların yüksek performans gösterdiği bilinciyle azalmıştır .

Müşteri noktasında, 2. maddede yükselttiğiniz LINQ gibi teknolojilerle sorgu yapma eğilimi de var .

SQL'in modülerleşmeye zorlanabileceğini kabul etmeme rağmen, müşteri tarafı kodu ile SQL arasında her zaman bir ikilik olmasına rağmen büyük adımlar atılmıştır - 4GL hatları biraz bulanıklaştırsa da.

Sanırım bu gerçekten DBA'lar / mimarlar / teknoloji liderlerinin bu konuda ne kadar istekli olduklarına bağlı. Vanilla SQL'den başka herhangi bir şeye izin vermeyi reddederlerse, çok fazla soru ile sonuçlanabilir. Eğer buna şaşırırsan, kafanı bir tuğla duvara çarpma, tırmandır. İşleri biraz uzlaşmayla yapmanın daha iyi yolları vardır - özellikle de faydaları kanıtlayabiliyorsanız.