Soru En kullanışlı veritabanı standartlarınız nelerdir?


Zamanla biriktirdiğim bazı fikirlerim var, ancak veritabanını modelleme sırasında işlerin sizin için nasıl kolaylaştığını gerçekten bilmek istiyorum:

  1. Tablo adı Birincil Anahtar adı ve açıklama anahtarı ile eşleşir
  2. Şemalar fonksiyonel alana göre
  3. Mümkünse kompozit ana anahtarlardan kaçının (benzersiz kısıtlamalar kullanın)
  4. Camel Case tablo isimleri ve alan adları
  5. Tabloları tbl_ ile veya SP_ ile proxy'leri (macar notasyonu yok)
  6. OLTP veritabanları BCNF / 4NF'de en az olmalıdır.

44


Menşei


"Mümkünse kompozit ana anahtarlardan kaçının" - Onları önlemek için hangi uzunluklara gideceksin? Ben, fazla değil. Ayrıca "benzersiz dizinler kullan" - "benzersiz kısıtlamalar" (ipucu: tüm SQL ürünleri endeksleri kullanmıyor) mu demek istediniz veya aklınızda belirli ürünleriniz var mı? - onedaywhen
İnsanlar cevabımı düşürdüğü için, yakında onu sileceğim, bunu yoruma koyacağım. NORMALİZASYON benimseyebileceğin en iyi standartlardan biridir. - Lance Roberts
@Tapoi: Neden 5 numara yapmıyorsunuz? Yanlış olduğunu söylemiyorum, bilmek isterim şirketimizde yaptığımız gibi gizler - Kezzer
Tecrübemde, birleşik ana anahtarları düzenli olarak kullanarak, iki tablo arasında 8-tuşlu birleşim ile dört seviye derinlikli olduğunuz bir duruma yönlendirirsiniz. Bir kod üreteci kullanmıyorsanız, SQL'i bu tür tablolara karşı yazmak oldukça sıkıcıdır. Benzersiz kısıtlamalar kullanmanızı öneriyorum. - Raj More
Standartlar hakkında en iyi şey, seçim yapabileceğiniz çok şey var! - araqnid


Cevaplar:


  • Aynı ön ekinle aynı şekilde planlanmış saklı proforları isimlendirin, örneğin Kişi için 3 saklı prosedürünüz varsa. Bu sayede kişi için her şey tek bir yerde toplanır ve onları bulmak için tüm proaktiflere bakmak zorunda kalmadan kolayca bulabilirsiniz.
    • PersonUpdate
    • PersonDelete
    • PersonCreate
  • İlgili verilere sahip tablo grupları olduğunda, tablolar için benzer şeyler yapın. Örneğin:
    • InvoiceHeaders
    • InvoiceLines
    • InvoiceLineDetails
  • Veritabanında şema seçeneği varsa, bunları kullanın. Görmek daha güzel:
    • Invoice.Header
    • Invoice.Line.Items
    • Invoice.Line.Item.Details
    • Person.Update
    • Person.Delete
    • Person.Create
  • Bu hedefe ulaşmak için başka makul bir yaklaşım yoksa tetikleyicileri kullanmayın.
  • Alan adlarına anlamlı bir önek verin, böylece hangi tabloyu açıklamaya ihtiyaç duymadan hangi tablodan geldiklerini söyleyebilirsiniz. Bu şekilde, başvurulan bir alan adı gördüğünüzde, hangi tablodan olduğunu kolayca anlayabilirsiniz.
  • Benzer verileri içeren alanlar için tutarlı veri türleri kullanın, diğer bir deyişle telefon numarasını sayısal olarak bir tabloda saklamayın ve diğerinde varchar. Aslında, sayısal olarak saklamayın, eğer negatif bir telefon numarasına rastlarsam çıldırırım.
  • Tablo / alan adlarında boşluk veya başka belirsiz karakterler kullanmayın. Tamamen alfasayısal olmalılar - ya da benim delilerimi alsaydım, alt çizgi haricinde tamamen alfabetik olsaydım. Şu anda masa ve alan adlarının boşluk, soru işareti ve ünlem işareti içerdiği kalıtsal bir sistem üzerinde çalışıyorum. Beni her gün tasarımcıyı öldürmek istiyor!
  • Sözdizimi anahtar sözcüklerini nesne adları olarak kullanmayın, baş ağrısından veri almayı dener. Nesne isimlerini [index] olarak sarmaktan nefret ediyorum ki bu iki gereksiz karaktere ihtiyacım yok!

19



@balabaster: Ben de bunu yapıyorum. İşleri iyi organize etmenize yardımcı olur. Daha sık, birden fazla arama var PersonGetByPersonId, PersonGetByName, PersonGetByOderId, PersonGetByCity .. Varlık adı ile kod öneki çok sıkı tutar. - Raj More
@balabaster: tablo ve sütun adlarında soru işaretleri ve ünlem işareti? Bunu görmemiştim. Senin için hissediyorum dostum! - Raj More
@Tapori: Evet, bazı insanlar beni merak ediyor, lol - BenAlabaster
+1 100 usp_Insert ... sprocs görmek için bir veritabanı açmak gibi bir şey yok - blu
Tetikleyiciler üzerindeki olumsuz yorum neden? - leora


Henüz görmediğim bir şey daha:

Veritabanı anahtar kelimeleri asla nesne adları olarak kullanmayın. Onları her kullandığınızda onları hak etmek zorunda kalmak istemezsiniz

Oluşturduğunuzda bir şeyi yanlış yazarsanız, fark ettiğiniz anda düzeltin. Bu tablodaki UserName'in gerçekten Usernmae olduğunu hatırlamak için yıllar harcamayın. Buna karşı çok fazla kod yazılmadığında düzeltmek çok daha kolay.

Hiçbir zaman ima edilen birleşimleri kullanmayın (virgül sözdizimi), her zaman birleştirmeleri belirtin.


13



Şemamızdaki Branches.barnchID gibi ... Buna çoktan alıştım ama başımda çok büyük baş ağrısına neden oldu. Şema iki farklı ürün tarafından kullanılıyor, bu yüzden yeniden adlandırmak gerçekten bir seçenek değildi. Ama sana katılıyorum. Olası olarak kısa sürede DÜZELTME MİSİNİZ! - Peter Perháč
Sanırım birkaç sene sonra da masalarımızda bir "care_hire_driver_id" ana anahtarımız var. - araqnid
İma edilen birleşmeler için +1, böyle sorguları tamir etmekten bıktım. - SqlACID
Dürüst olmak gerekirse, "zımni birleşme" yi daha basit ve kullanımı daha kolay buluyorum. Seçtiğiniz hangi tabloları anında görebilirsiniz, çünkü birbirlerinin hemen yanında listelenmişlerdir. "Tablo1, tablo2". İlk önce birleştirme alanlarını belirttiğiniz sürece sorun yoktur, örn. "WHERE table1.id = table2.table1id AND ..." - DisgruntledGoat
Ve unutma ki, adlandırma sisteminizden farklı olan tablo / alan adları - örneğin "Kullanıcılar" tablosunda çoğul ancak "İleti" tablosu için tekil - yanlış yazım olarak sayılır ve ASAP düzeltilmelidir. - DisgruntledGoat


Herkesin girdisini bir listeye koymak.

Adlandırma Standartları

  • Şemalar fonksiyonel alan olarak adlandırılır (Ürünler, Siparişler, Nakliye)
  • Macarca Notasyon Yok: Nesne adlarında tip adı yok (no strFirstName)
  • Nesne adları için kayıtlı anahtar kelimeler kullanmayın
  • Nesne adlarında boşluk ya da özel karakterler yok (Alphanumber + Underscore izin verilen tek şeydir)
  • Nesneleri doğal bir şekilde adlandırın (NameFirst yerine FirstName)
  • Tablo adı Birincil Anahtar Adı ve Açıklama alanıyla eşleşmelidir (SalesType - SalesTypeId, SalesTypeDescription)
  • Tbl_ veya sp_ ile önek yapmayın
  • Nesne adına göre isim kodu (CustomerSearch, CustomerGetBalance)
  • CamelCase veritabanı nesne isimleri
  • Sütun adları tekil olmalı
  • Tablo adları çoğul olabilir
  • Tüm kısıtlamalara iş adları verin (MustEnterFirstName)

Veri tipleri

  • Tablolar arasında aynı değişken türünü kullanın (Posta kodu - bir tabloda sayısal ve diğerinde varchar iyi bir fikir değildir)
  • Çok uluslu şirketlere gidebileceğinizi asla bilemeyeceğiniz müşteri bilgileri (ad, adres (ler)) vb. İçin nNVarChar kullanın.

Kodda

  • Anahtar kelimeler her zaman UPPERCASE içinde
  • Hiçbir zaman ima edilen birleşimleri kullanmayın (Comma sözdizimi) - her zaman açık INNER JOIN / OUTER JOIN kullanın
  • Satır başına bir JOIN
  • Satır başına bir WHERE maddesi
  • Döngü yok - set tabanlı mantıkla değiştirin
  • A, B, C yerine diğer adlar için kısa isimler çizelgeleri kullanın.
  • Rüşvet olmaması durumunda tetikleyiciden kaçının
  • Veba gibi imleçlerden kaçının (okuyun http://www.sqlservercentral.com/articles/T-SQL/66097/)

belgeleme

  • Veritabanı diyagramları oluştur
  • Bir veri sözlüğü oluştur

Normalizasyon ve Referans Bütünlük

  • Mümkün olduğunca tek sütunlu birincil anahtarlar kullanın. Gerektiğinde benzersiz kısıtlamalar kullanın.
  • Referans bütünlüğü her zaman uygulanacaktır.
  • CASCADE SİLMEYEN ÖNLEM
  • OLTP en az 4NF olmalıdır
  • Bire-çok arasındaki ilişkiyi, çoktan çoğa ilişki potansiyeli olarak değerlendirmek
  • Kullanıcı tarafından oluşturulmamış Birincil Anahtarlar
  • Güncelleme tabanlı yerine Ekleme tabanlı modeller oluşturun
  • FK'den FK'ye aynı isim olmalı (Employee.EmployeeId, EmployeeSalary.EmployeeId ile aynı alan)
  • İkili birleşim olduğunda (Person.PersonId, PersonRelation.PersonId_Parent ve PersonRelation.PersonId_Child öğelerine katılır)

Bakım: bulmak için periyodik komut dosyalarını çalıştırın

  • Tablo olmadan şema
  • Yetim kayıtları
  • Ana anahtarsız tablolar
  • Dizinsiz tablolar
  • Deterministik olmayan UDF
  • Yedekleme, Yedekleme, Yedekleme

İyi ol

  • Tutarlı ol
  • Hataları düzeltmek şimdi
  • Joe Celko'nun SQL Programlama Stili'ni (ISBN 978-0120887972) okuyun

11





Oracle için standartlarım:

  • Anahtar kelimeler her zaman UPPERCASE'dir;
  • Veritabanı nesne adları her zaman küçük harfle yazılır;
  • Alt düzlemler boşlukların yerini alacak (yani, SQL Server'da yaygın olan herhangi bir deve vakası sözleşmesi olmayacaktır);
  • Birincil anahtarlar hemen hemen her zaman 'id' olarak adlandırılacaktır;
  • Referans bütünlüğü uygulanacaktır;
  • Tamsayı değerleri (tablo kimlikleri dahil) genellikle her zaman NUMBER (19,0) olur. Bunun nedeni, bunun 64-bit imzalı bir tam sayıya sığması ve böylece daha uzun süredir BigInteger yerine Java uzun tipinin kullanılmasına izin vermesidir;
  • Bazı sütun adlarına "_number" ekleme misnomerine rağmen, bu tür sütunların türü VARCHAR2 bir sayı türü değil. Sayı türleri, aritmetik yaptığınız birincil anahtarlar ve sütunlar için ayrılmıştır;
  • Her zaman bir teknik birincil anahtar kullanırım; ve
  • Her tablonun anahtar üretimi için kendi sırası olacaktır. Bu dizinin adı _seq olacaktır.

SQL Server ile tek değişiklik veritabanı nesne isimleri için deve vakası kullanmaktır (örneğin, party_name yerine PartyName).

Sorgular, satır başına bir satır veya koşulla çok satırlı olarak yazılma eğiliminde olacaktır:

SELECT field1, field2, field2
FROM tablename t1
JOIN tablename2 t2 ON t1.id = t2.tablename_id
WHERE t1.field1 = 'blah'
AND t2.field2 = 'foo'

SELECT yan tümcesi yeterince uzunsa, her satıra bir alan ayırırım.


10



neredeyse tamamen Oracle ile çalışmak, her noktada sizinle aynı fikirdeyim. Bununla birlikte, çok fazla alt yazı yazmanın aksine CamelCase'in daha parmak dostu olduğunu düşünüyorum. Şemasında yaklaşık 200 tabloya sahip olan bir üçüncü taraf sistemimiz var ve alt çizgi kullanılmamasını tercih ettiler. Örneğin. PROJECT_TASK_TYPE yerine PROJECTTASKTYPE ve okumak biraz daha zor olsa da, daha kolay olduğu gibi sorguları yazmayı kabul etmeliyim. - Peter Perháč
SQL Server için de "old_school_names" kullanıyoruz. Bunun dışında ana farkımız, birincil anahtar-yedek olarak sadece "id" değil, zaman zaman yararlı olan "tablename_id" i kullanmayı tercih etmem olurdu; aynı zamanda, çoğu zaman, tablo A ve tablo B arasındaki bağlantının, aynı şekilde adlandırılmış sütunlar üzerinde yapıldığı anlamına gelir. purchase.purchase_type_id = purchase_type.purchase_type_id. Ayrıca, tablo adlarının çoğul değil ("satın alma" değil "satın alma") tekil olması gerektiğini belirtiyoruz. - araqnid
Mimarim, adın açık olmadığı birleştirme tabloları için alt çizgi kullanmak istediğini söyledi. Örneğin, Müşteri ve Ürün bir OrderId PK ile Siparişe katılırsa, belirlenir! Ancak Ürünler ve Kategori katıldığında ve birleştirme için bir işletme adı yoksa, Product_Category'i bir Product_Category_Id ile alırız. (SQL Server) - Raj More


  • Tüm kısıtlamaları adlandırın

9



Kısıtlamalara anlamlı isimler verme fikrini seviyorum. - Raj More


Veritabanlarınızı düzenli olarak yedeklemeyi unutmayın.


8



Bunu bir adım daha ileri götürürdüm. Her gün yedekle, haftalık olarak geri yükle. Yedekleri gerçekten geri yükleyebildiğinizi her zaman iki kez kontrol edin, aksi takdirde yedeklemelerinizin yeterince iyi olmadığını zor bir zamanda öğreneceksiniz. - Raj More


  1. Alan adlarında tip isimlerini kullanmayın. Yaşlılar, lpszFieldName'in eski MS standardını ve ortaya çıkan aptallığı hatırlayacaklar.

  2. Normal dil kurallarına uyan açıklayıcı alan adlarını kullanın. Örneğin "NameFirst" yerine "FirstName"

  3. Alan adındaki her kelime büyük harfle yazılmıştır

  4. Alt çizgiler yok

  5. "Dizin" gibi normal anahtar kelimeler kullanmayın

  6. Nesne tipi ile HERHANGİ bir önek yapmayın. Örneğin, tblCustomers veya spCustomersGet kullanmayın. Bunlar iyi sıralamaya ve sıfır değere izin vermez.

  7. Veritabanının ayrı alanlarını tanımlamak için şemaları kullanın. Satış gibi. Müşteriler ve hr.Employees. Bu, insanların kullandığı öneklerin çoğundan kurtulacaktır.

  8. Her türlü döngü şüpheyle görülmelidir. Genellikle daha iyi bir set tabanlı bir yol var.

  9. Karmaşık birleşimler için görünümleri kullanın.

  10. Mümkün olduğunda karmaşık birleşimlerden kaçının. Bir CustomerPhoneNumbers tablosuna sahip olmaktan daha fazla hevesli olabilir; ama dürüst olmak gerekirse, kaç tane telefon numarasına ihtiyacımız var? Sadece alanları Müşteriler tablosuna ekleyin. DB sorgularınız daha hızlı olacak ve anlaşılması daha kolay olacak.

  11. Bir tablo "EmployeeId" alanını çağırırsa, o zaman ona başvuran EVERY SINGLE TABLE bu ismi kullanmalıdır. Sadece bir uzantı tablosunda olduğu için CustomerServiceRepId çağrılmasına gerek yoktur.

  12. Hemen hemen tüm tablolarda "s" var. Örneğin: Müşteriler, Siparişler, vb. Tüm tablo birçok kayıt tuttuktan sonra ...

  13. Sorgularınızı, endekslerinizi ve yabancı anahtar ilişkilerini bir analiz aracıyla değerlendirin. Sizin için üretilebilecekler bile. Şaşırmış olabilirsin.

  14. Birçok ilişkiyi destekleyen tabloların bağlanması, adında hem bağlantılı tablolar var. Örneğin, SchoolsGrades. Tablo adıyla ne yaptığını söylemek çok kolay.

  15. Tutarlı ol. Sözleşmelerinizle bir yoldan başlarsanız, önceki çalışmaların tümünü yeniden düzenlemeye istekli olmadığınız sürece atları yarıya düşürmeyin. Bu, frenleri herhangi bir şeye koymalıydı, "eğer bu harika olmaz mıydı?"

  16. Yazmadan önce düşün. Bu masaya, tarlaya, sproza ​​ya da manzaraya gerçekten ihtiyacınız var mı? Başka bir yerde bulunmadığından emin misin? Eklemeden önce fikir birliği alın. Ve eğer bir sebepten dolayı onu çıkarmanız gerekiyorsa, önce ekibinizle konuşun. DBA'ların devleri dikkate almadan günlük kırılmaların değiştiği yerlerde bulundum. Bu eğlenceli değil.


7



Kesinlikle # 10 ile katılmıyorum, bu çok kötü bir uygulama çoğu zaman, yeni bir telefon tipi eklemek için tablo yapısını değiştirmek zorunda. Bazı insanlar için kaç tane telefon numarası saklamanız gerektiğine şaşıracaksınız. Yine de 8 ile katılıyorum. - HLGEM
# 10 için # 1. Overnormalization maliyetini abartmayın. - Andomar
@Joe, bazı anlamlı bilgilerle ön ek alırdım. IE, sorumluEmployeeId veya assistantEmployeeId - Nathan Koop
@Tapori, # 10'un muhtemelen sistem gereksinimlerine bağlı olduğunu kabul ediyorum. Ancak, örneklerin iyi olduğunu düşünmüyorum. Arama geçmişi için, gerçek telefon numarasını, tarih tablosunda kendisiyle aynı adrese koymak daha iyi olurdu. Sipariş tablosunda olmalıdır. Bunun nedeni, birilerinin kayıtları "telefon" veya "adresler" tablonuzdan silmesi durumunda bile tarihin bozulmadan kalmasıdır. Yinelenen veriler mi? Muhtemelen, ancak verilerinizi rapor etmek çok daha kolay ve bu alanlardaki veriler asla değişmemelidir. - NotMe
CONT: Telefon numarasını gerçek arama geçmişi ile aynı kayıtta tutarak, kullanıcı arayüzü / veri katmanı, hasarlı geçmişi dikkate almadan telefon numaralarını ana müşteri hesabıyla yönetebilir. Adres ve siparişlerle aynı. - NotMe