TSQL için kodlama standartları önerilebilir mi?

Uzun süredir .Net kodumuz için kodlama standartlarına sahibiz ve bunları nasıl uygulayacağımız konusunda zaman içinde gelişen fikirler için birkaç saygın kaynak var gibi görünüyor.

Ürünlerimiz tarafından kullanılmak üzere yazılmış SQL için bazı standartları bir araya getirebilmek istiyorum, ancak iyi yazılmış SQL'i neyin belirlediğine dair fikir birliği üzerinde orada herhangi bir kaynak yok gibi görünüyor?

Deneyimlerime göre, aradığım temel şeyler:

• Tablo ve sütun adlandırma - Kimlik türü sütunları için kimlik, Referans veya Sayı kullanıp kullanmadığınızı, adlar için tekil veya çoğul ifadeleri kullanın (çoğullar tablo adları için ortaktır - örneğin THINGS, sütun adları için tekil - örneğin THING_ID). Benim için buradaki en önemli şeyler, insanların zaman kaybetmesini önleyen tutarlılıktır (örneğin, birinin THING'i bir tablo adı olarak koyduğu yazım hatalarına girmezsiniz, çünkü sadece sezgisel olarak tablo adlarının asla tekil olmadığını bilirsiniz).

• Tüm oluşturmalar, dosyalarının bir parçası olarak bir damla (var olan nesneye bağlı) içermelidir. Ayrıca size hibe izinleri eklemek de isteyebilirsiniz.

• Seçimler, güncellemeler, eklemeler ve silme işlemleri, bir satır adı, bir tablo adı ve satır başına cümle ile yan tümce / sıraya göre düzenlenmelidir, böylece hata ayıklama sırasında birer birer kolayca yorumlanabilir.

• Özellikle karıştırılabilecekleri nesne türleri için önek (böylece v en önemli görünümdür). Hala uygulanıp uygulanmadığından emin değilim ancak sp_'yi başlatmak için sistem prosedürleri dışındaki saklı yordamlar için verimsizdi. Muhtemelen onları farklılaştırmak için en iyi uygulama usp_ en son kullandığım şeydi.

• Bir tetikleyicinin adının güncelleme / ekleme / silme ve uygulanacağı tablo için nasıl olması gerektiğini belirten bir standart. Tercih ettiğim bir standart yok, ancak bu kritik bir bilgidir ve bulunması kolay olmalıdır.

• SQL Server'ın önceki sürümlerinde veya 2005 ve sonraki sürümlerde bulunması gereken şemada nesnelerin sahipliği için standart. Bu sizin çağrınızdır, ancak hiçbir zaman kimin bir şeye sahip olduğunu / nerede yaşadığını tahmin etmemelisiniz) ve mümkünse şemanın / sahibinin yanlış oluşturulma olasılığını en aza indirmek için CREATE komut dosyalarına dahil edilmesi gerekir.

• SELECT * kullanan herkesin kendi idrarından bir bardak içeceği belirtisi.

• Gerçekten, gerçekten iyi bir neden (sizin tarafınızdan tembellik içermeyen) olmadığı sürece, başlangıçtan itibaren birincil anahtar / yabancı anahtar ilişkilerine sahip olun, uygulayın ve sürdürün. Sonuçta ilişkisel bir veritabanı düz bir dosya değildir ve yetim kayıtları bir noktada destek hayatınızı cehenneme çevirecektir. Ayrıca, şimdi yapmazsanız, olaydan sonra asla uygulamaya koymayacağınıza dair söz veremeyeceğimize dikkat edin, çünkü verilere sahip olduğunuzda işin 10 katı (asla zorlanmayacağınız için biraz vidalanacak) ilişkiler düzgün).

Eminim bir şeyleri kaçırdım ama benim için onlar gerçekten iyi durumlarda gerçekten fayda sağlayanlardır.

Ancak tüm standartlarda olduğu gibi, daha azı daha fazladır. Kodlama standartlarınız ne kadar uzun olursa, insanların bunları okuma ve kullanma olasılığı o kadar düşük olur. Birkaç iyi aralıklı sayfayı geçtikten sonra, gerçek dünyada gerçekten pratik bir fark yaratmayan şeyleri bırakmaya çalışın, çünkü insanların herhangi birini yapma şansını azaltmış olursunuz.

DÜZENLEME: iki düzeltme - sahiplik bölümündeki şemalar dahil, sayım (*) ile ilgili hatalı bir ipucunun kaldırılması - aşağıdaki yorumlara bakın.

iyi yazılmış SQL'i neyin belirlediğine dair fikir birliği üzerinde herhangi bir kaynak yok gibi görünüyor

Çünkü fikir birliği yoktur. Örnek olarak, Jon Hopkins'in listesindeki öğelerin en az yarısı için farklı cevaplarım olacaktı ve listesindeki ayrıntı miktarına dayanarak, ikimiz de yaşamak için veritabanlarıyla çalıştığımız güvenli bir tahmin.

Bununla birlikte, bir kodlama standardı hala sahip olmak için iyi bir şeydir ve takımdaki herkesin anladığı ve kabul ettiği bir standart daha iyi bir şeydir, çünkü bu standardın izlenmesi daha olasıdır.

Jon Hopkins'in cevabına ek olarak ...

• Dahili ve harici nesneleri ayırma

  • Kısıtlamalar ve indeksler için IX, UQ, TRG, CK vb.
  • küçük harf veya istemci karşı karşıya için CapsCase örn. uspThing_Add

• Dahili nesneler için "varsayılan olmayan" ise bunları açık yapın

  • UQ = benzersiz kısıtlama
  • UQC = benzersiz kümelenmiş kısıtlama
  • PK = birincil anahtar
  • PKN = kümelenmemiş birincil anahtar
  • IX = dizin
  • IXU = benzersiz dizin
  • IXC = kümelenmiş dizin
  • IXCU veya IXUC = benzersiz kümelenmiş dizin

• Adlandırma ve izinleri basitleştirmek için şemalar kullanın. Örnekler:

  • Dahili işlemler için Helper.xxx
  • Udfs için HelperFn.xxx
  • Bazı karşılıklı kodlar için WebGUI.xxx
  • Tablolar için Veri ve / veya Geçmiş ve / veya Hazırlama