En yaygın SQL anti-paternleri nelerdir? [kapalı]

İlişkisel veritabanlarıyla çalışan hepimiz SQL'in farklı olduğunu öğrendik (veya öğrendik). İstenen sonuçları elde etmek ve bunu verimli bir şekilde yapmak, kısmen tanıdık paradigmaları öğrenmek ve en tanıdık programlama kalıplarımızdan bazılarının burada çalışmadığını bulmakla sıkıcı bir süreç içerir. Gördüğünüz (veya kendiniz taahhüt ettiğiniz) ortak antipatterns nedir?

Çoğu programcının UI-mantığını veri erişim katmanında karıştırma eğilimi beni sürekli olarak hayal kırıklığına uğrattı:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Normalde, programcılar bunu yaparlar çünkü veri kümelerini doğrudan bir ızgaraya bağlamak isterler ve SQL Server biçiminin sunucu tarafında istemcideki biçimden daha kullanışlı olması yeterlidir.

Yukarıda gösterilene benzer sorgular son derece kırılgandır çünkü veri katmanını UI katmanıyla sıkıca birleştirirler. Bunun da ötesinde, bu programlama tarzı saklı yordamların yeniden kullanılabilir olmasını tamamen önler.

İşte ilk 3'üm.

Sayı 1. Alan listesi belirtilemedi. (Düzenleme: karışıklığı önlemek için: bu bir üretim kodu kuralıdır. Bir kerelik analiz komut dosyaları için geçerli değildir - yazar olmadıkça.)

SELECT *
Insert Into blah SELECT *

olmalı

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Sayı 2. Bir imleç ve while döngüsü kullanarak, loop değişkenli bir while döngüsü yapacağız.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Sayı 3. Dize türleri aracılığıyla DateLogic.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Olmalı

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

Yakın zamanda "Bir sorgu ikiden daha iyi, amiright?"

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Bu sorgu, parametrelerin değerlerine bağlı olarak iki veya üç farklı yürütme planı gerektirir. Bu sql metni için yalnızca bir yürütme planı oluşturulur ve önbelleğe yapıştırılır. Bu plan parametrelerin değerine bakılmaksızın kullanılacaktır. Bu, kesintili düşük performans ile sonuçlanır. İki sorgu (amaçlanan yürütme planı başına bir sorgu) yazmak çok daha iyidir.

• Okunabilir parola alanları , örn. Kendini açıklayıcı.

• Dizinlenmiş sütunlara karşı LIKE kullanma ve neredeyse genel olarak LIKE demeyi tercih ediyorum.

• SQL tarafından üretilen PK değerlerinin geri dönüşümü.

• Henüz kimse tanrı masasından bahsetmedi . Hiçbir şey 100 organik bit bayrağı, büyük dize ve tamsayı gibi "organik" demez.

• Sonra ".ini dosyalarını özlüyorum" deseni var: CSV'leri, sınırlandırılmış dizeleri veya diğer ayrıştırılmış verileri büyük metin alanlarında saklamak.

• Ve MS SQL sunucusu için hiç imleç kullanımı . Herhangi bir imleç görevini yapmanın daha iyi bir yolu var.

Düzenlendi çünkü çok fazla var!

Bunun için derinlemesine araştırma yapmak zorunda değilsiniz: Hazırlanmış ifadeler kullanmamak.

Anlamsız tablo takma adları kullanma:

from employee t1,
department t2,
job t3,
...

Büyük bir SQL ifadesini okumayı olması gerekenden çok daha zor hale getirir

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Körü körüne güvenen kullanıcı girişi
2. Kullanmama parametreli sorgular
3. Açık metin şifreleri

Benim ayılar benim Yönetici Direktörü en iyi arkadaş köpek damat ve 8 yaşındaki oğlu tarafından bir araya getirilmiş 450 sütun Erişim tabloları ve sadece birileri bir veri yapısını düzgün bir şekilde normalleştirmek için nasıl bilmiyorum çünkü var.

Genellikle, bu arama tablosu şöyle görünür:

ID INT,
İsim NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Tarih1 DATETIME,
Tarih2 DATETIME

Bu tür iğrençliklere dayanan sistemlere sahip gördüğüm müşteri sayısını kaybettim.

En çok sevmediğim

1. Tablo, sprocs vb. Oluştururken boşluk kullanma CamelCase veya under_scores ve tekil veya çoğul ve UPPERCASE veya küçük harf ile iyiyim ancak özellikle [garip aralıklıysa] bir tabloya veya sütuna [boşluklarla] başvurmak zorundayım (evet, Bunun içine girdim) gerçekten beni rahatsız ediyor.

2. Denormalize veriler. Bir tablonun mükemmel bir şekilde normalleştirilmesi gerekmez, ancak mevcut değerlendirme puanları veya birincil şeyleri hakkında bilgi sahibi olan bir çalışanlar tablosuyla karşılaştığımda, muhtemelen bir noktada ayrı bir tablo yapmam gerekeceğini ve sonra onları senkronize tutmaya çalışın. İlk önce verileri normalleştireceğim ve sonra denormalizasyonun yardımcı olduğu bir yer görürsem, dikkate alacağım.

3. Görünümlerin veya imleçlerin aşırı kullanımı. Görünümlerin bir amacı vardır, ancak her tablo bir görünüme sarıldığında çok fazladır. Birkaç kez imleç kullanmak zorunda kaldım, ancak genellikle bunun için başka mekanizmalar kullanabilirsiniz.

4. Giriş. Bir program bir anti-desen olabilir mi? İşimde SQL Server var, ancak bazı kişiler teknik olmayan kullanıcılara erişilebilirlik, "kullanım kolaylığı" ve "kolaylık" nedeniyle erişim kullanıyor. Burada girecek çok şey var, ama benzer bir ortamdaysanız, biliyorsunuz.

SP'yi saklama yordamı adının öneki olarak kullanın, çünkü önce özel olanlar yerine Sistem yordamları konumunda arama yapar.

Geçici tablo ve imleçlerin aşırı kullanımı.

Zaman değerlerini saklamak için sadece UTC saat dilimi kullanılmalıdır. Yerel saat kullanılmamalıdır.

SCOPE_IDENTITY () yerine @@ IDENTITY kullanılarak

Bu cevaptan alıntı :

• @@ IDENTITY geçerli oturumdaki herhangi bir tablo için oluşturulan tüm kimlik değerlerini tüm kapsamlarda döndürür. Burada dikkatli olmalısın, çünkü kapsamlar arasında. Geçerli ifadeniz yerine tetikleyiciden bir değer alabilirsiniz.
• SCOPE_IDENTITY geçerli oturumdaki herhangi bir tablo ve geçerli kapsam için oluşturulan son kimlik değerini döndürür. Genellikle ne kullanmak istiyorsunuz.
• IDENT_CURRENT , herhangi bir oturumda ve kapsamda belirli bir tablo için oluşturulan son kimlik değerini döndürür. Bu, yukarıdaki ikisi ihtiyacınız olan şey değilse (çok nadir), hangi tablodan değer istediğinizi belirtmenize olanak tanır. Kayıt eklemediğiniz bir tablo için geçerli KİMLİK değerini almak istiyorsanız bunu kullanabilirsiniz.

'Ölü' bir alanı, amaçlanmadığı bir şey için yeniden kullanmak (örneğin, kullanıcı verilerini bir 'Faks' alanında saklamak) - hızlı bir düzeltme olarak çok cazip!

select some_column, ...
from some_table
group by some_column

ve sonucun some_column tarafından sıralanacağını varsayarsak. Bunu varsayımın geçerli olduğu Sybase ile biraz gördüm (şimdilik).

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Ya da, her şeyi tek bir çizgiye sıkıştırmak.

• FROM TableA, TableB WHERESözdizimi yerine KATILIYORFROM TableA INNER JOIN TableB ON

• Bir sorgunun döndürüleceği varsayımlarında, bir ORDER BY deyimi koymadan belirli bir şekilde sıralanmıştır, çünkü bu yalnızca sorgu aracında test sırasında ortaya çıktığı şekildeydi.

Kariyerlerinin ilk altı ayında SQL öğrenmek ve gelecek 10 yıl boyunca hiçbir şey öğrenmemek. Özellikle pencereleme / analitik SQL özelliklerini öğrenmek ya da etkili bir şekilde kullanmamak. Özellikle over () ve by partition kullanımı.

Toplama işlevleri gibi pencere işlevleri, tanımlanmış bir satır kümesinde (grup) bir toplama gerçekleştirir, ancak grup başına bir değer döndürmek yerine, pencere işlevleri her grup için birden çok değer döndürebilir.

Pencereleme işlevlerine güzel bir genel bakış için O'Reilly SQL Yemek Kitabı Ek A'ya bakınız .

Sadece listeyi tamamlamak için şu anki favorimi buraya koymam gerekiyor. En sevdiğim antipatternim sorgularınızı test etmiyor .

Bu şu durumlarda geçerlidir:

1. Sorgunuz birden fazla tablo içeriyor.
2. Bir sorgu için en uygun tasarıma sahip olduğunuzu düşünüyorsunuz, ancak varsayımlarınızı test etmeye zahmet etmeyin.
3. Optimize edilmiş olup olmadığına dair hiçbir ipucu olmadan çalışan ilk sorguyu kabul edersiniz.

Ve atipik veya yetersiz verilere karşı yapılan testler dikkate alınmaz. Saklı bir yordamsa, test ifadesini bir yoruma yerleştirin ve sonuçlarıyla birlikte kaydedin. Aksi takdirde, sonuçları kodla birlikte bir yoruma koyun.

Geçici Tablo kötüye kullanımı.

Özellikle bu tür şeyler:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

Bir sorgudan geçici bir tablo oluşturmayın, yalnızca ihtiyacınız olmayan satırları silin.

Ve evet, üretim DB'lerinde bu formda kod sayfaları gördüm.

Aksine görüş: normalleşmeye aşırı takıntı.

Çoğu SQL / RBDB sistemi, normalleştirilmemiş verilerle bile oldukça yararlı olan bir çok özellik (işlem, çoğaltma) sağlar. Disk alanı ucuzdur ve getirilen verileri değiştirmek / filtrelemek / aramak, bazen 1NF şemasını yazmak ve içindeki tüm zorluklarla (karmaşık birleşimler, kötü alt seçimler) uğraşmaktan daha basit (daha kolay kod, daha hızlı geliştirme süresi) olabilir. , vb).

Aşırı normalleştirilmiş sistemlerin, özellikle erken gelişim aşamalarında genellikle erken optimizasyon olduğunu gördüm.

(üzerine daha fazla düşünce ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Ben sadece bir araya koymak, burada bazı SQL yanıtları dayalı SO.

Olay işleyicileri OOP için tetikleyicilerin veritabanlarına yönelik olduğunu düşünmek ciddi bir antipatterntir. Tabloda bir işlem (olay) gerçekleştiğinde tetiklenecek yalnızca eski mantığın tetikleyicilere yerleştirilebileceği algısı vardır.

Doğru değil. En büyük farklardan biri, tetikleyicilerin bir intikamla senkronize olmasıdır, çünkü bir satır işleminde değil, ayarlanmış bir işlemde senkronize olurlar. OOP tarafında, tam tersi olaylar, eşzamansız işlemleri gerçekleştirmenin etkili bir yoludur.

Herhangi bir yorum yapılmadan Saklı Yordamlar veya İşlevler ...

1) Bu "resmi" bir anti-desen bilmiyorum, ama ben bir veritabanı sütununda sihirli değer olarak dize değişmezleri sevmiyorum ve kaçınmaya çalışıyorum.

MediaWiki'nin 'image' tablosundan bir örnek:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Sadece farklı bir kasa fark ettim, kaçınılması gereken başka bir şey)

Int birincil anahtarları ile tablolara ImageMediaType ve ImageMajorMime int aramalar gibi durumlarda tasarlayın.

2) belirli NLS ayarlarına dayanan tarih / dize dönüştürme

CONVERT(NVARCHAR, GETDATE())

biçim tanımlayıcı olmadan

Bir sorgudaki özdeş alt sorgular.

• Değiştirilmiş Görünüm - Çok sık ve önceden haber verilmeden veya gerekçesiz olarak değiştirilen görünüm. Değişiklik ya en uygunsuz zamanda fark edilir ya da daha kötüsü yanlış olur ve asla fark edilmez. Belki biri bu sütun için daha iyi bir ad düşündüğü için başvurunuz kırılacaktır. Kural olarak görüşler, tüketicilerle sözleşme yaparken temel tabloların faydasını genişletmelidir. Sorunları düzeltin, ancak yeni bir görünüm oluşturmak için özellikler veya daha kötü değişiklik davranışı eklemeyin. Azaltmak için görünümleri diğer projelerle paylaşmayın ve platformlar izin verdiğinde CTE'leri kullanın . Mağazanızın bir DBA'sı varsa, muhtemelen görünümleri değiştiremezsiniz, ancak tüm görünümleriniz eski ve bu durumda işe yaramaz olacaktır.

• Paramed - Bir sorgunun birden fazla amacı olabilir mi? Muhtemelen ama okuyan bir sonraki kişi derin meditasyona kadar bilemez. Şu anda onlara ihtiyacınız olmasa bile, hata ayıklamak için "sadece" olsa bile, şansınız olacaktır. Parametrelerin eklenmesi bakım süresini azaltır ve işleri KURU tutar. Where yan tümcesiniz varsa parametreleriniz olmalıdır.

• VAKA olmayışı -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

En çok bulduğum ve performans açısından önemli bir maliyeti olabilir:

• Küme tabanlı ifade yerine imleç kullanma. Programcı doğru düşünürken bu sık sık olur sanırım.

• Türetilmiş bir tabloya birleştirme işi yapabiliyorsa ilişkili alt sorgular kullanarak.

Geçici tablolara, özellikle SQL Server'dan Oracle'a geçiş yapan kişilerin, geçici tabloları aşırı kullanma alışkanlığı vardır. Yuvalanmış select deyimlerini kullanmanız yeterlidir.

SQL uygulamalarını (hem tek tek sorgular hem de çok kullanıcılı sistemler) hızlı veya yavaş kılan şey hakkında iyi bir fikir sahibi olmadan sorgu yazan geliştiriciler. Buna cehalet de dahildir:

• çoğu sorgunun darboğazının CPU değil I / O olduğu göz önüne alındığında fiziksel I / O minimizasyon stratejileri
• farklı fiziksel depolama erişim türlerinin mükemmel etkisi (örneğin, fiziksel depolama alanınız SSD ise daha az olsa da, çok sayıda sıralı G / Ç, küçük rastgele G / Ç'den daha hızlı olacaktır!)
• DBMS zayıf bir sorgu planı oluşturuyorsa bir sorguyu el ile ayarlama
• kötü veritabanı performansının nasıl teşhis edileceği, yavaş bir sorgunun "hata ayıklanması" ve bir sorgu planının nasıl okunacağı (veya seçtiğiniz DBMS'nize bağlı olarak EXPLAIN)
• çok kullanıcılı uygulamalarda verimi optimize etmek ve kilitlenmeleri önlemek için kilitleme stratejileri
• veri kümelerinin işlenmesinde harmanlamanın ve diğer püf noktalarının önemi
• alanı ve performansı en iyi şekilde dengelemek için tablo ve dizin tasarımı (örn. dizinleri kaplama, dizinleri mümkün olduğunca küçük tutma, veri türlerini gereken minimum boyuta düşürme vb.)

SQL'i yüceltilmiş bir ISAM (Dizinlenmiş Sıralı Erişim Yöntemi) paketi olarak kullanma. Özellikle, SQL deyimlerini daha büyük de olsa tek bir deyimde birleştirmek yerine imleçleri iç içe yerleştirmek. Bu aynı zamanda 'optimize ediciyi kötüye kullanma' olarak da sayılır, çünkü aslında optimize edicinin yapabileceği pek bir şey yoktur. Bu, maksimum verimsizlik için hazırlanmamış ifadelerle birleştirilebilir:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

Doğru çözüm (neredeyse her zaman) iki SELECT ifadesini bir araya getirmektir:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

Çift döngü versiyonunun tek avantajı, iç döngü sona erdiği için Tablo1'deki değerler arasındaki boşlukları kolayca tespit edebilmenizdir. Bu kontrol sonu raporlarında bir faktör olabilir.

Ayrıca, uygulamada sıralama genellikle hayır-hayır.

Birincil anahtarları kayıt adresleri için yedek olarak kullanma ve yabancı anahtarları kayıtlara yerleştirilmiş işaretçiler için bir yedek olarak kullanma.