Kod sorgulama SQL sorguları

SQL sorgularını farklı satırlarda mı kırmalıyım? Örneğin üzerinde çalıştığım projede 1600 sütun alan bir sorgumuz var! 1600 + sekme karakteri. Bunun gibi sorular yazdım:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Ama benden onları bir sıraya koymamı istediler ve tarzımın kötü biçimlendirme olduğunu söylediler. Neden kötü uygulama?

Kaynak kontrol nedenleriyle, her bir yan tümce veya virgülden sonra satır izlerimiz var. Yukarıdakileriniz

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(sekme ve hizalamanın burada bir standardı yoktur, ancak virgüller genellikle önde gelir)

Yine de performans farkı yok.

1600 sütunluk bir sorgu, iyi bir DBA tarafından ciddi bir incelemeye ihtiyaç duyuyor gibi geliyor.

Bir sorgu karmaşıksa onu sararım. Çok basit değilse, çok uzun olmadıkça tek bir satır olarak bırakacağım, sonra tekrar sarmaya başlayacağım.

Her şey yönetilebilirlik ve bunun ne yapılması gerektiğini anlamakla ilgilidir, böylece kuruluşunuzda bazı kod formatlama kuralları yoksa, sarma veya sarmalamama anında karar verilebilir.

Re: kötü kodlama uygulaması olmak. Zorlukla! Çok iyi bir uygulama. Bu kadar uzun bir sorgu kullanmak için bildiğim iyi bir neden ve onu yeniden biçimlendirmek için birçok iyi neden yok. Daha önce söylediğim gibi, yetenekli bir DBA'nın muhtemelen üzerinde çalışması gerekiyor.

Akla gelen tek satırlı sorguların tek avantajı, bu sorguların göz ardı edilmesi biraz daha kolay olabilir. Bunun dışında gerçi ben boğulmuşum. Şahsen ben daha okunabilir, bölünmüş sorguları tercih ederim.

Çok satırlı yorumlar iyi, büyük miktarda SQL ile uğraşırken neredeyse hayati önem taşıyor. Programlama dilinizde yorumlu alıntılar varsa, daha da iyidir (çünkü birçok editör SQL sözdizimini vurgulayabilir).

Misal:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Düzinelerce satır (veya yüzlerce) sorgusuyla çalışırken, hem girinti hem de boşluk metinleri çalışabilir hale getirir.

Bu, özellikle bir tür programlama dili içinde büyük bir sorgu tanımlamak, sorguyu bir dize değişmezine yerleştirdiğinizi ve birleştirdiğinizi görmekle ilgilidir.

Derlenmiş bir dilse, hiç fark etmemelidir - derleyicinin yapacağı ilk optimizasyonlardan biri dize değişmezlerini otomatik olarak birleştirmektir, böylece yine de büyük bir dize ile sonuçlanırsınız.

Sözdizimine gelince, sorguyu kodunuzun dışına taşımayı düşünmelisiniz - ayrı bir .sql kaynak dosyasında saklayın ve yazılımınızın bu dosyayı okumasını sağlayın. Dinamik olarak oluşturulmuş bir sorgu değilse (yani belirli parametrelere bağlı olarak nereye-cümlecikleri vb. Eklenmişse) değişkenler için hazırlanmış ifadeler kullanın. Dinamik olarak oluşturulmuşsa, gerektiğinde ve gerektiğinde ekstra parametreler ekleyerek kendi değişkenlerinizi ekleyebilirsiniz.

1600 sütuna gelince, bunun için bir görünüm oluşturmayı ciddiye almayı öneriyorum.

SELECT column1, column2, .... column1600 from X where Y

alacaksın

SELECT * viewX'DEN NEREDE

Kendi kodunuzda çok daha özlü.

Sık sık karmaşık bir sorguyu gidermek için @glasnt tarafından ortaya konulan biçimi kullanıyorum, ancak genellikle tek bir satırda sorgular var.

Bu, sorunuza cevap vermeyebilir, ancak sorgunuzu daha küçük sorgulara ayırmanızı da şiddetle tavsiye ederim. Açıkçası bu sorguya bağlıdır, ancak sorgunuza ne kadar fazla cümle ve birleşim eklerseniz SQL motoru sorgunuzu daha az optimize edebilir.

Veritabanı satıcınız MySQL'in EXPLAIN (veya MSSQL'in SHOWPLAN_ALL ayarı) gibi, sorgunuzu optimize etmek için veritabanının perde arkasında ne yaptığını gösterecek araçlara sahip olmalıdır. birden fazla eşzamanlı kullanıcı hakkında konuşurken büyük gecikmeler.

Önemsiz mantık gibi görünen şeyleri SQL'den ve kodunuza taşıyarak, çarpıcı performans artışları sağlayabilirsiniz - SQL basit işlemlerde harikadır.

Sizinle ilgili olabileceği gibi bunun en belirgin yararı, sorgularınızın çok daha az karmaşık ve okunması kolay olmasıdır - yönetilmesi kolay (> 1600 sütun değil) ve daha hızlıdır. Kesinlikle çok yönlü bir galibiyet.

Bu yardımcı olur umarım :)